AUTOMATICALLY RECONNECTING A CLIENT ACROSS RELIABLE AND 

PERSISTENT COMMUNICATION SESSIONS 

CROSS REFERENCE TO RELATED APPLICATIONS 

[0001] This present application is a continuation-in-part of 
and claims priority to U.S. Patent Number 09/880,268, entitled 
'Method and Apparatus for Transmitting Authentication Credentials 
of a User Across Communication Sessions", filed June 1 3, 2001 , and 
U.S. Patent Application Number 10/683,881, entitled 'Encapsulating 
Protocol For Session Persistence And Reliability, filed October 10, 
2003, both of which are incorporated herein by reference. 

TECHNICAL FIELD 

[0002] The invention generally relates to network and client- 
server communications. More particularly, the invention relates to 
systems and methods for re-establishing client communications 
using a communication protocol that encapsulates other protocols 
to provide session persistence and reliability and for facilitating the 
reauthentication of a user using a client computer to communicate 
with a server computer via the encapsulating protocol. 



BACKGROUND OF THE INVENTION 

[0003] Communications over a network between two 
computers, for example a client and a server, can be implemented 
using a variety of known communication protocols. Often, however, 
the network connection is susceptible to breakdown. For instance, 
a wireless connection between a client and a server is often 
unreliable. In other cases, the network connection is intermittent. 
As such, a connection can be lost when one enters an elevator or 
tunnel and may only be restored following one's exit from the 
elevator or tunnel. 

[0004] If an established communication session between the 
client and the server computer abnormally terminates, the client 
generally has to re-establish the connection by starting a new 
communication session. To begin the new communication session, 
the user typically has to retransmit the authentication credentials, 
such as a login /password pair, to the server computer so that the 
server computer can authorize the user for the new communication 
session. This retransmission of the authentication credentials of a 
user across multiple communication sessions repeatedly exposes 
the authentication credentials of that user to potential attackers, 



thereby decreasing the level of security of the authentication 
credentials. In addition, this often is a slow process that also 
results in user frustration and inefficiency. Furthermore, in 
establishing a new communication session, the network may require 
the client obtains a new network identifier, such as an internet 
protocol address. The applications or programs on the client may 
need to be restarted because of the change in the client's network 
identifier. Thus, it is desirable to provide a technique for 
automatically re-authenticating a client when a communication 
session between a client computer and a server computer is re- 
established without requiring repeated transmission of the clients 
authentication credentials or restarting of programs. 

[0005] Improved systems and methods are needed for re- 
establishing a communication session between a client computer 
and a server computer without repeatedly transmitting the 
authentication credentials. 

BRIEF SUMMARY OF THE INVENTION 

[0006] The present invention relates to systems and 
methods for providing a client with a persistent and reliable 
connection to a host service and for reconnecting the client to the 



persistent and reliable connection. Reconnecting the client includes 
re-establishing the clients communication session with the host 
service and re-authenticating the user of the client to the host 
service. A persistent and reliable connection to a host service is 
maintained by a first protocol service on behalf of a client. The first 
protocol service ensures that data communicated between the client 
and the host service is buffered and maintained during any 
disruption in the network connection with the client and the first 
protocol service. For example, a temporary disruption in a network 
connection may occur when a client, such as a mobile client, roams 
between different access points in the same network, or when a 
client switches between networks {e.g., from a wired network to a 
wireless network). When roaming between different access points, 
the client may need to be assigned a different network identifier, 
such as an internet protocol address, as required by the network 
topology. In addition to maintaining buffered data during a 
network disruption, the first protocol service re-authenticates the 
client to the host service when re-establishing the clients 
connection to the first protocol service. After re-authenticating, the 
first protocol service re-links the clients connection to the host 
service. This prevents the user of the client from re-entering 



authentication credentials to re-establish its connection with the 
host service. Furthermore, the first protocol service will 
automatically manage changes to the client's network identifier that 
may need to occur after a network disruption. This prevents the 
user from restarting any applications or programs that would 
customarily need to be restarted when the client's assigned network 
identifier changes. The user can seamlessly continue using the 
client as the user roams between network access points without 
interruption from changes by the network to the client's assigned 
network identifier. In summary, the present invention provides 
automatic reconnection of a disrupted client connection to a host 
service without restarting applications or re-establishing sessions, 
including re-authentication without the user reentering 
authentication credentials. 

[0007] In one aspect, the invention relates to a method for 
reconnecting a client to a host service after a disruption to a 
network connection. The method uses a first protocol service to re- 
establish the connection between a client and a host service. The 
method includes providing a first connection between a client and a 
first protocol service and a second connection between the first 



protocol service and a host service. When a disruption is detected 
in the first connection, the second connection between the first 
protocol service and the host service is maintained. Then the first 
connection between the client and the first protocol service is re- 
established. The first protocol service receives a ticket associated 
with the client and validates the ticket. After the ticket is validated, 
the re-established first connection is linked to the maintained 
second connection. 

[0008] In one embodiment of the invention, the method 
includes further validating the ticket before linking the re- 
established first connection with the maintained second connection. 
The validating method further includes obtaining a session 
identifier and a key from the ticket received by the first protocol 
service. The session identifier from the ticket is used to retrieve the 
stored and encrypted authentication credentials of the client. Then 
the key from the ticket is used to decrypt the retrieved 
authentication credentials. 

[0009] In another embodiment, the invention provides for 
re-authentication of the client to the host service when re- 
establishing the clients connection to the host service. The method 



further includes authenticating the client to the host service when 
providing the first connection between the client and the first 
protocol service and the second connection between the first 
protocol service and the host service. When re-establishing the first 
connection after a disruption in the connection is detected, the 
method further includes re-authenticating the client to the host 
service. 

[001 0] In another embodiment of the invention, the method 
further includes the first protocol service generating a ticket 
associated with the client. Additionally, the method further includes 
deleting the ticket after it is validated. In another embodiment, the 
ticket can be automatically deleted after a pre-determined period of 
time. Moreover, after the ticket is deleted, a replacement ticket can 
be generated. In another embodiment, a copy of the ticket can be 
saved at the first protocol service. Furthermore, the ticket can be 
transmitted from the first protocol service to the client. 

[001 1 ] In another aspect, the invention relates to a system 
for reconnecting a client to host service after a disruption to a 
network connection. The system re-establishes the connection 
between a client and a host service using a first protocol service. 



The client is configured to maintain a first connection with the first 
protocol service. The first protocol service is configured to maintain 
the first connection with the client and a second connection with the 
host service. In accordance with this system, a disruption is 
detected in the first connection and the first connection is re- 
established between the client and the first protocol service while 
the second connection between the first protocol service and the 
host service is maintained. The client transmits a ticket associated 
with the client to the first protocol service. The ticket is validated 
and, after it is validated, the first protocol service links the re- 
established first connection with the maintained second connection. 

[0012] In one embodiment of the invention, the system 
includes further validating the ticket before linking the re- 
established first connection with the maintained second connection. 
Validation of the ticket further includes obtaining a session 
identifier and a key from the ticket received by the first protocol 
service. The session identifier from the ticket is used to retrieve the 
stored and encrypted authentication credentials of the client. Then 
the system decrypts the retrieved authentication credentials by 
using the key from the ticket. 



[001 3] In another embodiment, the invention provides a 
system for re-authenticating the client to the host service when re- 
establishing the client connection to the host service. The system 
further includes authenticating the client to the host service when 
providing the first connection between the client and the first 
protocol service and the second connection between the first 
protocol service and the host service. When re-establishing a 
connection after detecting a disruption in the connection, the 
system uses the retrieved authenticated credentials to re- 
authenticate the client to the host service 

[0014] In another embodiment of the invention, the system 
further includes the first protocol service generating a ticket 
associated with the client. Additionally, the system further includes 
deleting the ticket, after it is validated. In one embodiment, the 
first protocol service will automatically delete the ticket after a pre- 
determined period of time. Moreover, after the ticket is deleted, the 
system generates a replacement ticket. In another embodiment, the 
first protocol service saves a copy of the ticket. Furthermore, the 
first protocol service can transmit the ticket to the client. 



BRIEF DESCRIPTION OF THE DRAWINGS 

[001 5] The foregoing and other objects, aspects, features, 
and advantages of the invention will become more apparent and 
may be better understood by referring to the following description 
taken in conjunction with the accompanying drawings, in which: 

[001 6] FIG. 1 A is a block diagram of a system for providing a 
client with a reliable connection to a host service according to an 
illustrative embodiment of the invention; 

[001 7] FIG. 1 B is a block diagram of a system for providing a 
client with a reliable connection to a host service according to 
another illustrative embodiment of the invention; 

[001 8] FIG. 2A depicts communications occurring over a 
network according to an illustrative embodiment of the invention; 

[001 9] FIG. 2B depicts communications occurring over a 
network according to another illustrative embodiment of the 
invention; 

[0020] FIG. 3 depicts a process for encapsulating a plurality 
of secondary protocols within a first protocol for communication 



over a network according to an illustrative embodiment of the 
invention; 

[0021 ] FIG. 4 is a block diagram of an embodiment of a 
computer system to maintain authentication credentials in 
accordance with the invention; 

[0022] FIG. 5A is a flow diagram of the steps followed in an 
embodiment of the computer system of FIG. 5 to maintain 
authentication credentials during a first communication session in 
accordance with the invention; 

[0023] FIG. 5B is a flow diagram of the steps followed in an 
embodiment of the computer system of FIG. 4 to maintain 
authentication credentials during a second communication session 
following the termination of the first communication session of FIG. 
6A in accordance with the invention; 

[0024] FIG. 6 is a block diagram of an embodiment of a 
computer system to maintain authentication credentials in 
accordance with another embodiment of the invention; 

[0025] FIG. 7 A is a flow diagram of the steps followed in an 
embodiment of the computer system of FIG. 6 to maintain 



authentication credentials during a first communication session in 
accordance with the invention; 

[0026] FIG. 7B is a flow diagram of the steps followed in an 
embodiment of the computer system of FIG. 6 to maintain 
authentication credentials during a second communication session 
following the termination of the first communication session of FIG. 
6 in accordance with the invention; 

[0027] FIG. 7C is a flow diagram of the steps followed in an 
embodiment of the computer system of FIG. 6 to maintain 
authentication credentials during a second communication session 
following the termination of a second communication channel of the 
first communication session of FIG. 6 in accordance with the 
invention; 

[0028] FIG. 8A is a block diagram of a system to maintain 
authentication credentials and provide a client with a reliable 
connection to a host service according to an illustrative 
embodiment of the invention; 

[0029] FIG. 8B is a block diagram of a system to maintain 
authentication credentials and provide a client with a reliable 



connection to a host service according to another illustrative 
embodiment of the invention; 

[0030] FIG. 9A is a block diagram of a system to maintain 
authentication credentials and provide a client with a reliable 
connection to a host service according to another illustrative 
embodiment of the invention; 

[0031 ] FIG. 9B is a block diagram of a system to maintain 
authentication credentials and provide a client with a reliable 
connection to a host service according to another illustrative 
embodiment of the invention; 

[0032] FIG. 1 OA is a block diagram of a system for providing 
a client with a reliable connection to a host service and further 
including components for reconnecting the client to a host service 
according to an illustrative embodiment of the invention; 

[0033] FIG. 1 0B is a block diagram of an embodiment of a 
system for providing a client with a reliable connection to a host 
service and further including components for reconnecting the 
client to a host service; 



[0034] FIG. 1 1 A is a block diagram of an embodiment of FIG. 
1 OA further including components for initially connecting the client 
to a host service; 

[0035] FIG. 1 1 B is a block diagram of the illustrative system 
of FIG. 1 OB further including components for initially connecting the 
client to a host service and to maintain authentication credential 
according to an illustrative embodiment of the invention; 

[0036] FIG. 1 2A is a flow diagram of a method for network 
communications according to an illustrative embodiment of the 
invention; 

[0037] FIG. 1 2B is a flow diagram of a method for 
reconnecting the client to the host services; 

[0038] FIGS. 1 3A-1 3C are flow diagrams of a method for 
connecting a client to a plurality of host services according to an 
illustrative embodiment of the invention; 

[0039] FIG. 1 4 is a flow diagram of a method for providing a 
client with a reliable connection to host services and for 
reconnecting the client to the host services according to an 
illustrative embodiment of the invention; and 



[0040] FIGS. 1 5A-1 5B are flow diagrams of a method for 
reconnecting a client to host services according to an illustrative 
embodiment of the invention. 

DETAILED DESCRIPTION OF THE INVENTION 

[0041] Certain embodiments of the present invention are 
described below. It is, however, expressly noted that the present 
invention is not limited to these embodiments, but rather the 
intention is that additions and modifications to what is expressly 
described herein also are included within the scope of the invention. 
Moreover, it is to be understood that the features of the various 
embodiments described herein are not mutually exclusive and can 
exist in various combinations and permutations, even if such 
combinations or permutations are not made express herein, without 
departing from the spirit and scope of the invention. 

[0042] Referring to FIG. 1A, in general, the invention 
pertains to network communications and can be particularly useful 
for providing a client with a reliable connection to a host service. In 
a broad overview, a system 1 00 for network communications 
includes a client 1 08 {e.g., a first computing device) in 
communication with a first protocol service 1 1 2 {e.g., a second 



computing device) over a network 1 04. Also included in the system 
1 00 are a plurality of host services 1 1 6a-l 1 6n {e.g., third 
computing devices) that are in communication, over a network 1 04', 
with the first protocol service 1 1 2 and, through the first protocol 
service 1 1 2 and over the network 1 04, with the client 1 08. 
Alternatively, in another illustrative embodiment of the invention, 
and with reference now to FIG. 1 B, the first protocol service 1 1 2 and 
the host services 1 1 6a-l 1 6n are not implemented as separate 
computing devices, as shown in FIG. 1 A, but, rather, they are 
incorporated into the same computing device, such as, for example, 
host node 1 1 8a. The system 1 00 can include one, two, or any 
number of host nodes 1 1 8a-l 1 8n. 

[0043] In one embodiment, the networks 104 and 104' are 
separate networks, as in FIG. 1A. The networks 104 and 104' can be 
the same network 1 04, as shown in FIG. 1 B. In one embodiment, 
the network 1 04 and/or the network 1 04' is, for example, a local- 
area network (LAN), such as a company Intranet, or a wide area 
network (WAN), such as the Internet or the World Wide Web. The 
client 1 08, the first protocol service 1 1 2, the host services 1 1 6a- 
1 1 6n, and/or the host nodes 1 1 8a-l 1 8n can be connected to the 



networks 1 04 and/or 1 04' through a variety of connections 
including, but not limited to, standard telephone lines, LAN or WAN 
links {e.g., 802.1 1 , Tl , T3, 56kb, X.25), broadband connections 
{e.g., ISDN, Frame Relay, ATM), wireless connections, or some 
combination of any or all of the above. 

[0044] Moreover, the client 108 can be any workstation, 
desktop computer, laptop, handheld computer, mobile telephone, 
or other form of computing or telecommunications device that is 
capable of communication and that has sufficient processor power 
and memory capacity to perform the operations described herein. 
Additionally, the client 1 08 can be a local desktop client on a local 
network 1 04 or can be a remote display client of a separate network 
1 04. The client 1 08 can include, for example, a visual display device 
{e.g., a computer monitor), a data entry device {e.g., a keyboard), 
persistent and/or volatile storage {e.g., computer memory), a 
processor, and a mouse. An example of a client agent 1 28 with a 
user interface is a Web Browser (e.g. a Microsoft® Internet Explorer 
browser and/or Netscape™ browser). 

[0045] Similarly, with reference to FIG. 1A, each of the first 
protocol service 1 1 2 and the host services 1 1 6a- 1 1 6n can be 



provided on any computing device that is capable of communication 
and that has sufficient processor power and memory capacity to 
perform the operations described herein. Alternatively, where the 
functionality of the first protocol service 1 1 2 and the host services 
1 1 6a-l 1 6n are incorporated into the same computing device, such 
as, for example, one of the host nodes 1 1 8a-l 1 8n, as in FIG. 1 B, 
the first protocol service 1 1 2 and/or the host services 1 1 6a-1 1 6n 
can be implemented as a software program running on a general 
purpose computer and/or as a special purpose hardware device, 
such as, for example, an ASIC or an FPGA. 

[0046] Similar to the client 1 08, each of the host nodes 
1 1 8a-l 1 8n can be any computing device described above (e.g. a 
personal computer) that is capable of communication and that has 
sufficient processor power and memory capacity to perform the 
operations described herein. Each of the host nodes 1 1 8a-l 1 8n can 
establish communication over the communication channels 124a- 
1 24n using a variety of communication protocols (e.g., ICA, HTTP, 
TCP/IP, and IPX). SPX, NetBIOS, Ethernet, RS232, and direct 
asynchronous connections). 



[0047] In one embodiment, each of the host services 1 16a- 
1 1 6n hosts one or more application programs that are remotely 
available to the client 1 08. The same application program can be 
hosted by one or any number of the host services 1 1 6a-l 1 6n. 
Examples of such applications include word processing programs, 
such as MICROSOFT WORD, and spreadsheet programs, such as 
MICROSOFT EXCEL, both of which are available from Microsoft 
Corporation of Redmond, Washington. Other examples of 
application programs that may be hosted by any or all of the host 
services 1 16a-l 16n include financial reporting programs, customer 
registration programs, programs providing technical support 
information, customer database applications, and application set 
managers. Moreover, in one embodiment, one or more of the host 
services 1 1 6a-l 1 6n is an audio/video streaming server that 
provides streaming audio and/or streaming video to the client 1 08. 
In another embodiment, the host services 1 1 6a-l 1 6n include file 
servers that provide any/all file types to the client 1 08. 

[0048] Referring still to the illustrative embodiments of FIGS. 
1 A and 1 B, the client 1 08 is configured to establish a connection 
1 20 between the client 1 08 and a first protocol service 1 1 2 over the 



network 1 04 using a first protocol. For its part, the first protocol 
service 1 1 2 is configured to accept the connection 1 20. The client 
1 08 and the first protocol service 1 1 2 can, therefore, communicate 
with one another using the first protocol as described below in 
reference to FIGS. 2A-2B and FIG. 3. 

[0049] In some embodiments, as shown in FIGS. 1 A and 1 B, 
a client agent 1 28 is included within the client 1 08. The client 
agent 1 28 can be, for example, implemented as a software program 
and/or as a hardware device, such as, for example, an ASIC or an 
FPGA. The client agent 1 28 can use any type of protocol and it can 
be, for example, an HTTP client agent, an FTP client agent, an Oscar 
client agent, a Telnet client agent, an Independent Computing 
Architecture (ICA) client agent from Citrix Systems, Inc. of Fort 
Lauderdale, Florida, or a Remote Desktop Procedure (RDP) client 
agent from Microsoft Corporation of Redmond, Washington. In 
some embodiments, the client agent 1 28 is itself configured to 
communicate using the first protocol. In some embodiments (not 
shown), the client 1 08 includes a plurality of client agents 1 28a- 
1 28n, each of which communicates with a host service 1 1 6a-l 1 6n, 
respectively. 



[0050] In another embodiment, a standalone client agent is 
configured to enable the client 1 08 to communicate using the first 
protocol. The standalone client agent can be incorporated within 
the client 1 08 or, alternatively, the standalone client agent can be 
separate from the client 1 08. The standalone client agent is, for 
example, a local host proxy. In general, the standalone client agent 
can implement any of the functions described herein with respect to 
the client agent 1 28. 

[0051 ] As also described further below, the first protocol 
service 112 is, in one embodiment, itself configured to 
communicate using the first protocol. The first protocol service 1 1 2 
is configured to establish a connection 1 24a-l 24n between the first 
protocol service 1 1 2 and the host service 1 1 6a- 1 1 6n, respectively. 
For example, the first protocol service 1 1 2 can establish a 
connection 1 24a between the first protocol service 1 1 2 and one 
host service 1 1 6a and a connection 1 24b between the first protocol 
service 1 1 2 and another host service 1 1 6b. In one embodiment, the 
first protocol service 108 separately establishes such connections 
1 24a-l 24n (i.e., the first protocol service 1 1 2 establishes one 
connection at a time). In another embodiment, the first protocol 



service 1 1 2 simultaneously establishes two or more of such 
connections 124a-124n. 

[0052] In yet another embodiment, the first protocol service 
1 1 2 can concurrently establish and maintain multiple connections 

I 24a-l 24n. The first protocol service 1 1 2 is configured to provide 
two or more connections 1 24a-l 24n without interrupting the 
connection 1 20 with the client 1 08. For example, the first protocol 
service 1 1 2 can be configured to establish the connection 1 24a 
between the first protocol service 1 1 2 and the host service 1 1 6a 
when a user of the client 1 08 requests execution of a first 
application program residing on the host service 1 16a. When the 
user ends execution of the first application program and initiates 
execution of a second application program residing, for example, 
on the host service 1 1 6b, the first protocol service 1 1 2 is, in one 
embodiment, configured to interrupt the connection 1 24a and 
establish the connection 1 24b between the first protocol service 

I I 2 and the host service 1 1 6b, without disrupting the connection 

I 20 between the first protocol service 1 1 2 and the client 1 08. 

[0053] The first protocol service 1 1 2 and the host services 

I I 6a-l 1 6n can communicate over the connections 1 24a-l 24n, 



respectively, using any one of a variety of secondary protocols, 
including, but not limited to, HTTP, FTP, Oscar, Telnet, the ICA 
remote display protocol from Citrix Systems, Inc. of Fort Lauderdale, 
Florida, and/or the RDP remote display protocol from Microsoft 
Corporation of Redmond, Washington. For example, the first 
protocol service 1 1 2 and the host service 1 1 6a can communicate 
over the connection 1 24a using the ICA remote display protocol, 
while the first protocol service 1 1 2 and the host service 1 1 6b can 
communicate over the connection 1 24b using the RDP remote 
display protocol. 

[0054] In one embodiment, the secondary protocol used for 
communicating between the first protocol service 1 1 2 and a host 
service 1 16, such as, for example, the ICA remote display protocol, 
includes a plurality of virtual channels. A virtual channel is a 
session-oriented transmission connection that is used by 
application-layer code to issue commands for exchanging data. For 
example, each of the plurality of virtual channels can include a 
plurality of protocol packets that enable functionality at the remote 
client 108. In one embodiment, one of the plurality of virtual 
channels includes protocol packets for transmitting graphical screen 



commands from a host service 1 16, through the first protocol 
service 1 1 2, to the client 1 08, for causing the client 1 08 to display a 
graphical user interface. In another embodiment, one of the 
plurality of virtual channels includes protocol packets for 
transmitting printer commands from a host service 1 16, through 
the first protocol service 1 1 2, to the client 1 08, for causing a 
document to be printed at the client 1 08. 

[0055] In another embodiment, the first protocol is a 
tunneling protocol. The first protocol service 1 12 encapsulates a 
plurality of secondary protocols, each used for communication 
between one of the host services 1 1 6a-l 1 6n and the first protocol 
service 1 1 2, within the first protocol. As such, the host services 
1 1 6a-l 1 6n and the first protocol service 1 1 2 communicate with the 
client 1 08 via the plurality of secondary protocols. In one 
embodiment, the first protocol is, for example, an application-level 
transport protocol, capable of tunneling the multiple secondary 
protocols over a TCP/IP connection. 

[0056] Referring to FIG. 2A, communications between the 
client 1 08 and the first protocol service 1 1 2 via the connection 1 20 
take the form of a plurality of secondary protocols 200a-200n {e.g., 



HTTP, FTP, Oscar, Telnet, ICA, and/or RDP) encapsulated within a 
first protocol 204. This is indicated by the location of secondary 
protocols 200a-200n inside the first protocol 204. Where secure 
communication is not called for, the first protocol 204 can be, as 
illustrated in FIG. 2A, communicated over an unsecured TCP/IP 
connection 208. 

[0057] Referring now to FIG. 2B, if secure communication is 
used, the first protocol 204 is communicated over an encrypted 
connection, such as, for example, a TCP/IP connection 21 2 secured 
by using a secure protocol 216 such as the Secure Socket Layer 
(SSL). SSL is a secure protocol first developed by Netscape 
Communication Corporation of Mountain View, California, and is 
now a standard promulgated by the Internet Engineering Task Force 
(IETF) as the Transport Layer Security (TLS) protocol and described 
in IETF RFC-2246. 

[0058] Thus, the plurality of secondary protocols 200a-200n 
are communicated within the first protocol 204 with (FIG. 2B) or 
without (FIG. 2A) a secure protocol 21 6 over the connection 1 20. 
The secondary protocols that can be used to communicate over the 
connections 1 24a-l 24n include, but are not limited to, HTTP, FTP, 



Oscar, Telnet, ICA, and RDP. Moreover, in one embodiment, at least 
one of the secondary protocols, as described above, includes a 
plurality of virtual channels, each of which can include a plurality of 
protocol packets enabling functionality at the remote client 1 08. 
For example, in one embodiment, one host service 1 1 6a is a web 
server, communicating with the first protocol service 1 1 2 over the 
connection 1 24a using the HTTP protocol, and another host service 
1 16b is an application server, communicating with the first protocol 
service 1 1 2 over the connection 1 24b using the ICA protocol. The 
host service 1 1 6b generates both protocol packets for transmitting 
graphical screen commands to the client 1 08, for causing the client 
1 08 to display a graphical user interface, and protocol packets for 
transmitting printer commands to the client 1 08, for causing a 
document to be printed at the client 1 08. 

[0059] Another aspect of the present invention is the 
method and systems described herein reduce the number of times 
network connections are opened and closed. In one embodiment, 
the first protocol 204 allows the secondary protocol connections 
200a-200n tunneled therein, such as, for example, an HTTP 
connection 200n, to be opened and/or closed, repetitively, without 



also requiring the transport connection over which the first protocol 
204 is communicated (e.g., TCP connection 208 and/or 21 2), the 
secure protocol connection 216, or the first protocol connection 
204 itself to similarly be repetitively opened and/or closed. Without 
the encapsulation of the first protocol 204, the secondary protocol 
200a-200n may frequently open and close network connections, 
such as TCP connections. This would add significant delays and 
overhead to the system. These delays and overhead would be 
further increased by the use of a secure encapsulation protocol 214, 
such as SSL, which have significant overhead in establishing 
network connections. By encapsulating the secondary protocol 
200a-200n within the first protocol 204 and maintaining the 
connection of the transport connection (208, 212), the secondary 
protocols 200a-200n, as part of the payload of the first protocol 
204, do not need to perform frequent and costly open and closes of 
the network connection 1 20. Furthermore, since the secondary 
protocols 200a-200n can be communicated within the first protocol 
204 with a secure protocol 216, the secondary protocols 200a- 
200n also do not need to open and close secured connections such 
as with SSL. The transport connection (208, 21 2) establishes and 
maintains the network connection 1 20 so that the encapsulated 



second protocols 200a-200n can be communicated without 
repetitively opening and closing the secured or unsecured network 
connection 1 20. This significantly increases the speed of operation 
in communicating the secondary protocols 200a-200n. 

[0060] As described above, the secondary protocols 200a- 
200n carry protocol packets related to applications using such 
protocols as HTTP, FTP, Oscar, Telnet, RDA or ICA. The secondary 
protocol packets 304a-304n transport data related to the 
application functionality transacted between the client 108 and the 
host service 1 1 6a-l 1 6n. For example, a user on the client 1 08 may 
interact with a web page provided by a host service 1 1 6a- 1 1 6n. In 
transactions between the client 1 08 and the host service 1 1 6a- 
1 16n, the secondary protocol 200a-200n encapsulated in the first 
protocol 204 may have http protocol packets related to displaying 
the web page and receiving any user interaction to communicate to 
the host service 1 1 6a-l 1 6n. Since the transport connection (208, 
212) is not maintained by the secondary protocols 200a-200n, the 
secondary protocols 200a-200n do not need to handle any 
network-level connection interruptions. As such, the secondary 
protocols 200a-200n may not provide any network-level 



connection interruption information in their payloads. In the above 
example, the http related secondary protocol packets 304a-304n of 
the secondary protocol 200a-200n transmitted to the client 108 
would not provide a notification that a network interruption 
occurred, e.g., an error message on a web page. Therefore, the 
user on the client 108 will not be notified of any network-level 
connection interrupts through the secondary protocol 200a-200n. 
This effectively hides the network connection interruptions from the 
user during the use of the applications related to the secondary 
protocols 200a-200n. 

[0061] Referring to FIG. 3, an example process 300 used by 
the first protocol service 1 1 2 and the client agent 1 28 of the client 
1 08 encapsulates the plurality of secondary protocols 200 (e.g., 
HTTP, FTP, Oscar, Telnet, ICA, and/or RDP) within the first protocol 
204 for communication via the connection 1 20. Optionally, as 
described below, the example process 300 used by the first 
protocol service 1 1 2 and the client agent 1 28 of the client 1 08 also 
compresses and/or encrypts the communications at the level of the 
first protocol prior to communications via the connection 1 20. 
From the point of view of the first protocol service 1 1 2, secondary 



protocol packets 304a-304n are received via the connections 1 24a- 
1 24n at the first protocol service 1 1 2. For example, two secondary 
protocol packets 304a and 304b are received by the first protocol 
service 1 1 2. One, two, or any number of secondary protocol 
packets 304a-304n can be received. In one embodiment, the 
secondary protocol packets 304a-304n are transmitted by the host 
services 1 1 6 to the first protocol service 1 1 2 over the connection 
1 24. The secondary protocol packets 304a-304n include a header 
308 and a data packet 312, also referred to as a data payload. 

[0062] Following receipt of the secondary protocol packets 
304a-304n, the first protocol service 1 1 2 encapsulates one or more 
of the secondary protocol packets 304 within a first protocol packet 
316. In one embodiment, the first protocol service 1 1 2 generates a 
first protocol packet header 320 and encapsulates within the data 
payload 324 of the first protocol packet 31 6 one or more secondary 
protocol packets 304a-304n, such as, for example, two secondary 
protocol packets 304a and 304b. In another embodiment, only one 
secondary protocol packet 304a is encapsulated in each first 
protocol packet 316. 



[0063] In one embodiment, the first protocol packets 316 
are then transmitted over the connection 1 20, for example over the 
connection 208 described with reference to FIG. 2A, to the client 
agent 1 28 of the client 1 08. Alternatively, in another embodiment, 
the first protocol service 1 1 2 is further configured to encrypt, prior 
to the transmission of any first protocol packets 316, 
communications at the level of the first protocol 204. In one such 
embodiment, the first protocol packets 316 are encrypted by using, 
for example, the SSL protocol described with reference to FIG. 2B. 
As a result, a secure packet 328, including a header 332 and an 
encrypted first protocol packet 31 6' as a data payload 336, is 
generated. The secure packet 328 can then be transmitted over the 
connection 1 20, for example over the secure TCP/IP connection 21 2 
illustrated in FIG. 2B, to the client agent 1 28 of the client 1 08. 

[0064] In another embodiment, the first protocol service 1 1 2 
is further configured to compress, prior to the transmission of any 
first protocol packets 316, communications at the level of the first 
protocol 204. In one embodiment, prior to encrypting the first 
protocol packet 316, the first protocol service 1 1 2 compresses, 



using a standard compression technique, the first protocol packet 
316. As such, the efficiency of the system 1 00 is improved. 

[0065] Referring again to FIGS. 1 A-1 B, the system 1 00 of the 
present invention, in one embodiment, provides the remote client 
1 08 with a persistent connection to a host service 1 1 6, such as, for 
example, the host service 1 1 6a. For example, if the client 1 08 
establishes a connection 1 20 between the client 1 08 and the first 
protocol service 1 1 2 and the first protocol service 1 1 2 establishes a 
connection 1 24a between the first protocol service 1 1 2 and the host 
service 1 1 6a, then either the client agent 1 28, the first protocol 
service 1 1 2, or both are configured to maintain a queue of the first 
protocol data packets most recently transmitted via the connection 
1 20. For example, the queued data packets can be maintained by 
the client agent 1 28 and/or the first protocol service 1 1 2 both 
before and upon a failure of the connection 1 20. Moreover, upon a 
failure of the connection 1 20, the first protocol service 1 1 2 and, 
likewise, the host service 1 1 6a are configured to maintain the 
connection 1 24a. 

[0066] Following a failure of the connection 1 20, the client 
1 08 establishes a new connection 1 20 with the first protocol service 



1 1 2, without losing any data. More specifically, because the 
connection 124a is maintained upon a failure of the connection 
1 20, a newly established connection 1 20 can be linked to the 
maintained connection 1 24a. Further, because the most recently 
transmitted first protocol data packets are queued, they can again 
be transmitted by the client 1 08 to the first protocol service 1 1 2 
and/or by the first protocol service 1 1 2 to the client 1 08 over the 
newly established connection 1 20. As such, the communication 
session between the host service 1 1 6a and the client 1 08, through 
the first protocol service 112, is persistent and proceeds without 
any loss of data. 

[0067] In one embodiment, the client agent 1 28 of the client 
1 08 and/or the first protocol service 1 1 2 number the data packets 
that they transmit over the connection 1 20. For example, each of 
the client agent 1 28 and the first protocol service 1 1 2 separately 
numbers its own transmitted data packets, without regard to how 
the other is numbering its data packets. Moreover, the numbering 
of the data packets can be absolute, without any re-numbering of 
the data packets, i.e., the first data packet transmitted by the client 
agent 1 28 and/or the first protocol service 1 1 2 can be numbered as 



No. 1 , with each data packet transmitted over the connection 1 20 
by the client agent 1 28 and/or the first protocol service 1 1 2, 
respectively, consecutively numbered thereafter. 

[0068] In one such embodiment, following a disrupted and 
re-established connection 1 20, the client agent 1 28 and/or the first 
protocol service 1 1 2 informs the other of the next data packet that 
it requires. For example, where the client agent 1 28 had received 
data packets Nos. 1 -1 0 prior to the disruption of connection 1 20, 
the client agent 128, upon re-establishment of the connection 120, 
informs the first protocol service 1 1 2 that it now requires data 
packet No. 1 1 . Similarly, the first protocol service 1 1 2 can also 
operate as such. Alternatively, in another such embodiment, the 
client agent 1 28 and/or the first protocol service 1 1 2 informs the 
other of the last data packet received. For example, where the 
client agent 1 28 had received data packets Nos. 1-10 prior to the 
disruption of connection 1 20, the client agent 1 28, upon re- 
establishment of the connection 120, informs the first protocol 
service 1 1 2 that it last received data packet No. 1 0. Again, the first 
protocol service 1 1 2 can also operate as such. In yet another 
embodiment, the client agent 1 28 and/or the first protocol service 



1 12 informs the other, upon re-establishment of the connection 

I 20, of both the last data packet received and the next data packet 
it requires. 

[0069] In such embodiments, upon re-establishment of the 
connection 1 20, the client agent 1 28 and/or the first protocol 
service 1 1 2 can retransmit the buffered data packets not received 
by the other, allowing the communication session between a host 
service 1 1 6 and the client 1 08, through the first protocol service 

I I 2, to proceed without any loss of data. Moreover, upon re- 
establishment of the connection 1 20, the client agent 1 28 and/or 
the first protocol service 1 1 2 can flush from each of their respective 
buffers the buffered data packets now known to be received by the 
other. 

[0070] By providing the client 1 08 with a reliable and 
persistent connection to a host service 1 1 6a-l 1 6n, the present 
invention avoids the process of opening a new user session with the 
host service 1 1 6a-l 1 6n by maintaining the user session through 
network connection interruptions. For each user session with a host 
service 1 1 6a-l 1 6n, the client 1 08 and the host service 1 1 6a-l 1 6n 
may maintain session specific context and caches, and other 



application specific mechanisms related to that instance of the user 
session. For each new user session established, these session 
specific context and caches need to be re-populated or re- 
established to reflect the new user session. For example, a user on 
the client 1 08 may have an http session with a host service 1 1 6a- 
1 1 6n. The host service 1 1 6a- 1 1 6n may keep context specific to 
providing this instance of the http session with the client 108. The 
context may be stored in the memory of the server, in files of the 
server, a database or other component related to providing the 
functionality of the host service 1 1 6a-l 1 6n. Also, the client 1 08 
may have local context specific to the instance of the http session, 
such as a mechanism for keeping track of an outstanding request to 
the host service 1 1 6a-l 1 6n. This context may be stored in memory 
of the client 1 08, in files on the client 1 08, or other software 
component interfaced with the client 108. If the connection 
between the client 1 08 and the host service 1 1 6a-l 1 6n is not 
persistent, then a new user session needs to be established with 
new session specific context on the host service 1 1 6a-l 1 6n and the 
client 108. The present invention maintains the session so that a 
new session, and therefore new specific session context, does not 
need to be re-established. 



[0071] The present invention maintains the user session 
through network level connection interruptions and without 
notification to the user of the client that the session was 
interrupted. In operation of this aspect of the invention, the first 
protocol service 1 1 2 establishes and maintains a first connection 
with a client 1 08 and a second connection with a host service 1 1 6a- 
1 1 6n. Via the first connection and the second connection, a session 
between the client 1 08 and the host service 1 1 6a-l 1 6n is 
established. The first protocol service 1 1 2 can store and maintain 
any session related information such as authentication credentials, 
and client 1 08 and host service 1 1 6a-l 1 6n context for the 
established session. A user on the client 1 08 will exercise the 
functionality provided by the host service 1 1 6a-l 1 6n through the 
established session. As such, related secondary protocol packets 
304a-304n will contain data related to the transaction of such 
functionality. These secondary protocol packets 304a-304n as part 
of the secondary protocol 200a-200n are encapsulated and 
communicated in a first protocol 204. Upon detection of a 
disruption in either the first connection or the second connection, 
the first protocol service 1 12 can re-establish the disrupted 
connection while maintaining the other connection that may have 



not been disrupted. The network connection disruption may cause 
an interruption to the session between the client 1 08 and the host 
service 1 1 6a-l 1 6n. However, since the transport mechanism is not 
maintained by the secondary protocols 200a-200n, the session can 
be re-established after the network connection is re-established 
without the user on the client 1 08 having notification that the 
session was interrupted. The secondary protocol 200a-200n does 
not need to contain any interruption related information to transmit 
to the client 108. Thus, the interruption of the session caused by 
the network connection disruption is effectively hidden from the 
user because of the encapsulation of the first protocol 204. 

[0072] The first protocol service 1 1 2 maintaining session 
related information can re-establish the session between the client 
1 08 and the host service 1 1 6a-l 1 6n. For example, if the first 
connection between the client 1 08 and the first protocol service 1 1 6 
is disrupted, the first protocol service 1 1 2 can keep the clients 108 
session active or open between the first protocol service 1 1 2 and 
the host service 1 1 6a-l 1 6n. After the first connection is re- 
established, the first protocol service 1 12 can link the session of the 
client 1 08 to the maintained session between the first protocol 



service 1 1 2 and the host service 1 1 6. The first protocol service 1 1 2 
can send to the client 1 08 any data that was queued prior to the 
disruption in the first connection. As such, the client 1 08 will be 
using the same session prior to the disruption, and the host service 
1 1 6a-l 1 6n and client 1 08 can continue to use any session specific 
context that may have in memory or stored elsewhere. 
Furthermore, because of the intermediary of the first protocol 
service 1 1 2, the host service 1 1 6a- 1 1 6n may not be aware of the 
network disruption between the first protocol service 1 1 2 and the 
client 1 08. 

[0073] In another example, if the second connection 
between the first protocol service 1 1 2 and the host service 1 1 6a- 
1 1 6n is disrupted, the first protocol service can maintain the first 
connection with the client 108 while re-establishing the second 
connection with the host service 1 1 6a-l 1 6n. After re-establishing 
the second connection, the first protocol service 1 1 2 can re- 
establish the clients session, on behalf of the client, with the host 
service 1 1 6a- 1 1 6n. Since the first protocol service 1 1 2 was 
maintaining any session relation information, the first protocol 
service may re-establish the same session or a similar session so 



that the client 108 is not aware of the disruption in the second 
network connection and the resulting disruption to the session 
between the first protocol service 1 1 2 and the host service 1 1 6a- 
1 16n. During re-establishing the second network connection and 
the session, the first protocol service 1 1 2 can queue any session 
transactions sent by the client 1 08 during the disruption. Then, 
after re-establishing the session with the host service 1 1 6a-1 1 6n, 
the first protocol service 1 1 2 can transmit the queued transactions 
to the host service 1 1 6a-l 1 6n and the session can continue 
normally. In this manner, the client 1 08 continues to operate as if 
there was not an interruption to the session. 

[0074] Additionally, by providing a reliable and persistent 
connection, the present invention also avoids interruptions to 
transactions, commands or operations as part of the functionality 
exercised between the client 1 08 and a server 41 5, or a host service 
1 1 6a-l 1 6n. For example, a file copy operation using Windows 
Explorer has not been designed to continue working after there is a 
disruption in a network connection. A user on the client 1 08 may 
use the file copy feature of Windows Explorer to copy a file from the 
client 1 08 to a server 41 5. Because of the size of the file or files, 



this operation may take a relatively extended period of time to 
complete. If during the middle of the operation of the copy of the 
file to the server 41 5, there is an interruption in the network 
connection between the client 1 08 and the server 41 5, the file copy 
will fail. Once the network connection is re-established, the user 
will need to start another file copy operation from Windows Explorer 
to copy the file from the client 1 08 to the server 41 5. Under the 
present invention, the user would not need to start another file copy 
operation. The network connection would be re-established as part 
of the first protocol 204 connection. The file copy operations would 
be encapsulated in the payload of the secondary protocols 200a- 
200n. As such, the file copy of Windows Explorer would not get 
notified of the interruption in the network connection and therefore, 
would not fail. The first protocol service 1 1 2 would re-establish 
any connections and transmits any queued data so that operation 
can continue without failure. The first protocol service 1 1 2 would 
maintain a queue of the data related to the file copy operations that 
has not been transferred to the server 41 5 because of the 
interruption in the network connection. Once the network 
connection is re-established, the first protocol service 1 1 2 can 



transmit the queued data and then continue on with transferring the 
data related to the file copy operation in due course. 

[0075] Although this aspect of the invention is described in 
terms of a file copy operation example, one ordinarily skilled in the 
art will recognize that any operation, transaction, command, 
function call, etc. transacted between the client 1 08 and the server 
41 5, or host service 1 1 6a-l 1 6n, can be maintained and continued 
without failure from the network connection disruption, and, 
furthermore, without the client 108 recognizing there was a 
disruption or having notice of the disruption. 

[0076] Furthermore, by providing a reliable and persistent 
connection, the present invention also enables a client 1 08 to 
traverse through different network topologies without re-starting a 
session or an application on the client 1 08. For example, the client 
1 08 may be a computer notebook with a wireless network 
connection. As the client 1 08 moves from a first wireless network 
to a second wireless network, the clients network connection 1 20 
may be temporarily disrupted from the first wireless network as a 
network connection is established with the second wireless network. 
The second wireless network may assign a new network identifier, 



such as a host name or internet protocol address, to the client 1 08. 
This new network identifier may be different than the network 
identifier assigned to the client 1 08 by the first wireless network. In 
another example, the client 1 08 may be physically connected 
through an Ethernet cable to a port on the network. The physical 
connection may be unplugged and the client 1 08 moved to another 
location to plug into a different port on the network. This would 
cause a disruption into the network connection 1 02 and possible a 
change in the assigned network identifier. Without the present 
invention, any sessions with a host service 1 1 6a-l 1 6n on the client 
1 08 or application on the client 1 08 accessing the network may 
need to be restarted due to the change in the network topology, the 
disruption to the network connection 1 20, and/or the change in the 
assigned network identifier. By the method and systems described 
herein, the present invention maintains the network connection for 
the client and automatically re-established the clients 108 network 
connection including handling changes in the network topology and 
network identifier. The client 1 08, and any applications or sessions 
on the client 1 08, can continue to operate as if there was not a 
network connection disruption or a change in the network identifier. 
Furthermore, the user on the client 1 08 may not recognize there 



were any interruptions or changes, and the client 1 08 may not 
receive any notice of such interruptions. 

[0077] Even with a reliable and persistent communication 
session as described above, network connections are still disrupted. 
When re-establishing the client's connection to the host service, the 
client 1 08 also needs to be re-authenticated to the host service 
1 1 6. One embodiment of the invention relates to systems and 
methods for authenticating a client 1 08 to a host service 1 1 6 and 
re-authenticating the client 1 08 to the host service 1 1 6 without re- 
entering authentication credentials. 

[0078] FIG. 4 depicts an illustrative embodiment of a system 
400 that is capable of reconnecting the client 1 08 to a host service 
1 1 6 using an automatic client reconnect service referred to as auto 
client reconnect service or ACR Service 405. In brief overview, a 
client 1 08 communicates with a server computer 41 5, also referred 
to as a server, over a communication channel 41 8. The 
communication channel 41 8 may include a network 1 04. For 
example, the communication channel 41 8 can be over a local-area 
network (LAN), such as a company Intranet, or a wide area network 
(WAN) such as the Internet or the World Wide Web. The server 41 5 



provides auto client reconnect services through an ACR Service 405. 
The client 1 08 accesses the server 41 5 through the communication 
channel 41 8. The ACR Service 405 of the server 41 5 provides 
authentication services to authenticate the client 1 08 to the server 
41 5. When there is a disruption in a network connection, the ACR 
Service 405 further provides re-authentication services to re- 
authenticate the client 1 08 to the server 41 5. Although illustrated 
with a single client 1 08 and one communication channel 41 8, any 
number of clients (e.g. 1 08, 1 08') and number of communication 
channels (e.g. 41 8, 41 8) can be part of the system 1 00. 

[0079] In one embodiment, the server 41 5 includes a 
processor 425 and memory 430 that communicates over a system 
bus 432. The memory 430 may include random access memory 
(RAM) and/or read only memory (ROM). In another embodiment, the 
server 41 5 accesses memory 430 from a remote site (e.g., another 
computer, an external storage device). 

[0080] The ACR Service 405 running on the server 41 5 
includes a key generator 435, a session identifier (SID) generator 
438, an encryptor 440, a key destroyer 445, and a decryptor 448. 
The key generator 435 generates a key when the server 41 5 or the 



ACR Service 405 receives authentication credentials from the client 
1 08. In one embodiment, the key generator 435 derives the key 
from a characteristic of the server 41 5. Particular examples include 
the key generator 435 deriving the key from the temperature of the 
processor 425, the time that server 41 5 received the authentication 
credentials, and the number of keys stored in memory 430. In a 
further embodiment, the key and the authentication credentials are 
the same size (e.g. eight bits). In one embodiment, the key 
generator is a software module. In another embodiment, the key 
generator 435 is a random number generator. 

[0081 ] The SID generator 438 generates the unique SID to 
enable the server 41 5 to identify a particular communication 
session. In one embodiment, the SID generator 438 is a software 
module. In another embodiment, the SID generator 438 is a random 
number generator. In another embodiment, the SID generator 
transmits the SID to the host service 116. In one embodiment, the 
SID generator 438 obtains the SID from a host service 1 1 6 running 
on the server. In yet another embodiment, the SID generator 
generates the SID by receiving a session identifier from the host 
servicel 16 establishing a user session.. 



[0082] The encryptor 440 encrypts the key with the 
authentication credentials to create encrypted authentication 
credentials. In one embodiment, the encryptor 440 encrypts the key 
with the authentication credentials by performing an exclusive OR 
operation (i.e. XOR) on the key and the authentication credentials. In 
another embodiment, the encryptor 440 adds the authentication 
credentials to the key to encrypt the authentication credentials; that 
is, the encryptor 440 performs a "Caesar Cipher" on the 
authentication credentials using the key as the shift value. In 
another embodiment, the encryptor 440 performs a hash function, 
such as MD4, MD5, or SHA-1 , on the authentication credentials. It 
should be clear that the encryptor 440 can perform any type of 
manipulation on the authentication credentials as long as the ACR 
Service 405 can decrypt the encrypted authentication credentials 
with the key. 

[0083] In one embodiment, the encryptor 440 is a software 
module that executes mathematical algorithms on the key and the 
authentication credentials to create the encrypted authentication 
credentials. In another embodiment, the encryptor 440 is a logic 



gate of the server computer 41 5, such as an exclusive OR (XOR) 
gate. 

[0084] In one embodiment, the encryptor 440 stores the 
encrypted authentication credentials with the SID in a table 455 in 
memory 430. In another embodiment, the encryptor 440 stores the 
encrypted authentication credentials in the table 455 and the SID 
generator 438 stores the SID in the table 455. In one embodiment, 
the table 455 is an area in memory 430 allocated by the processor 
455 for us by the encryptor 440. In another embodiment, the 
encryptor 440 stores the encrypted authentication credentials with 
the SID in a database (not shown in Fig. 4) separate from memory 
430. 

[0085] In one embodiment, the ACR Service 405 uses the SID 
as a vector to the location of the encrypted authentication 
credentials in the table 455. In another embodiment, the ACR 
Service 405 uses the SID as a database key to locate and retrieve the 
encrypted authentication credentials in a database (not shown in 
Fig. 4). Each encrypted authentication credential created by the 
encryptor 440 is associated with only one unique SID. Thus, the ACR 



Service 405 can locate and retrieve the encrypted authentication 
credentials by using a particular SID. 

[0086] The key destroyer 445 deletes the key once the ACR 
Service 405 determines that the key is no longer needed. In one 
embodiment, the key destroyer 445 is a delete function of a 
software program such as the operating system of the server 41 5. 

[0087] The decryptor 448 decrypts the encrypted 
authentication credentials once the ACR Service 405 receives the 
key and the SID from the client 1 08. In one embodiment, the 
decryptor 448 is a software module that performs the inverse 
function or algorithm that the encryptor 440 performed to create 
the encrypted credentials. In another embodiment, the decryptor 
448 is a hardware component (e.g. a logic gate) to perform the 
inverse operation of the encryptor 440. 

[0088] In one embodiment, one or more of the key generator 
435, the SID generator 438, the encryptor 440, the key destroyer 
445 and the decryptor 448 are joined into one software module 
representing the ACR Service 405. In another embodiment, these 
components (436, 438, 440, 445 and 448) can be hardware 
components such as logic gates. In a further embodiment, these 



components (435, 438, 440, 445 and 448) are included in a single 
integrated circuit. In yet another embodiment, some of the 
components, for example the key generator 435 and the SID 
generator 438, can be hardware components, and other 
components, for example the encryptor 440, the key destroyer 445 
and the decryptor 448, can be software components. 

[0089] In another embodiment, the present invention also 
provides methods for reconnecting a client 1 08 to a host service 
1 1 6 when there is a disruption in the clients connection to the 
network. The methods include re-establishing the clients 
connection to the host service 1 1 6 and using the ACR Service 405 
to re-authenticate the client to the host service. 

[0090] Referring to FIG. 5A, the client 1 08 establishes a first 
communication session with the server 41 5 over the communication 
channel 41 8. The client 1 08 obtains (step 500) authentication 
credentials from a user of the client 1 08. In a system 1 00 not using 
an Open System Interconnection (OSI) protocol as the transmission 
protocol for communications between the client 1 08 and the server 
41 5, the authentication credentials may be a login password that is 
needed to establish the first communication session. In this 



embodiment, the obtaining of the authentication credentials from 
the user precedes the establishment of the communication session. 
In another embodiment, the authentication credential is personal 
information of the user that the client 1 08 obtains after the first 
communication session has been established. Examples of 
authentication credentials include a login password, a social 
security number, a telephone number, an address, biometric 
information, a time-varying pass code and a digital certification. 
The client 1 08 then transmits (step 505) the authentication 
credentials to the server 41 5 over the communication channel 41 8 
so that the server 41 5 can authenticate the client 1 08 or the user of 
the client 1 08. 

[0091 ] After the server 41 5 receives the authentication 
credentials, the ACR Service 405 provides its auto client reconnect 
services. The key generator 435 creates (step 51 0) a first encryption 
key for use with the authentication credentials. In one embodiment, 
the encryption key is a random number. In another embodiment, 
the encryption key is any standard cryptographic key. The encryptor 
440 then encrypts (step 51 5) the authentication credentials with the 
first key to generate encrypted authentication credentials. This 



prevents an attacker who gains access to the server 41 5 from 
accessing the authentication credentials without the key. The SID 
generator 438 then creates (step 520) a first SID to identify the first 
communication session between a client 1 08 and the server 41 5. In 
one embodiment, the first communication session is with a host 
service 1 1 6 hosted by the server 41 5. The encryptor 440 then 
stores (step 525) the encrypted authentication credentials with the 
first SID in the table 455 described above. 

[0092] In one embodiment, the encryptor 440 stores the 
encrypted authentication credentials with the first SID in a certain 
location for more efficient retrieval at a later time. For instance, the 
encryptor 440 stores all encrypted authentication credentials and 
SIDs that have been created within a predetermined amount of time 
in RAM 30. The ACR service 405 transfers all encrypted 
authentication credentials and SIDS created before a predetermined 
time to a second, external memory (not shown). In another 
embodiment, the encryptor 440 stores the encrypted authentication 
credentials with the SID in a database (not shown). 

[0093] The SID and the encrypted authentication credentials 
stored in the memory 430 can be arranged in any particular order 



and/or format. For example, the SID and encrypted authentication 
credentials can be stored in chronological order with respect to the 
creation time of the encrypted authentication credentials. 

[0094] The server 41 5 then transmits (step 535) the first key 
and associated first SID to the client 1 08 over the network 1 04. The 
client 1 08 stores (step 540) the first key and the first SID in the 
clients 1 08 memory (not shown). Then the key destroyer 445 of the 
ACR Service 405 deletes (step 545) the key stored in memory 430. 

[0095] In another embodiment, the ACR Service 405 does 
not delete the first key from memory 430 until the ACR Service 405 
has notification that the client 1 08 has received the key. For 
example, the client 1 08 transmits an acknowledgment message to 
the server 41 5 after the client 1 08 successfully received the key. 
Once the ACR Service 405 receives notification, the key destroyer 
445 then deletes (step 545) the key from the memory 430. This 
prevents the ACR Service 405 from deleting the key before the client 
1 08 successfully received the key. By not deleting the key until the 
acknowledgment message, the ACR Service 405 can retransmit the 
key and the SID to the client 1 08 upon a failure in the transmission. 



[0096] By deleting the key in step 545, the ACR Service 405 
does not have the mechanism needed to decrypt the encrypted 
authentication credentials stored in the table 455. Thus, if an 
attacker accesses the memory 430 of the server 41 5, the attacker 
can retrieve the encrypted authentication credentials but cannot 
decrypt the encrypted authentication credentials. Therefore, the 
attacker cannot read the authentication credentials. In short, the 
encrypted authentication credentials stored on the server 41 5 do 
not provide any information that the attacker can interpret or 
understand. As such, the server 41 5 does not possess any 
information to decrypt the encrypted authentication credentials. 

[0097] In addition, the client 1 08 is the only device that can 
provide the key to the encrypted authentication credentials. With 
the possibility of many clients 1 08 as part of the network 1 04, an 
attacker may have to attempt to gain access to each client (e.g. 1 08, 
1 08") individually to find the client 1 08 that possesses the correct 
key. This can be time consuming and tedious and, as a result, may 
deter an attacker from an attempt to decrypt the encrypted 
authentication credentials. 



[0098] In another embodiment, the server 41 5 has a timeout 
feature with respect to accessing the encrypted authentication 
credentials. For instance, the server 41 5 starts a timer after the first 
communication is abnormally terminated. If the timer reached a 
predetermined value before the client 108 re-establishes the 
second communication session and transmits the key to the server 
41 5 for decryption, the ACR Service 405 deletes the encrypted 
authentication credentials from the table 455. If no timer is used, 
the key acts as a de facto password for future sessions. 

[0099] Once the client 1 08 receives the first key and the first 
SID from the server 41 5 as described above in reference to FIG. 5A, 
the session can be re-established, as shown in FIG. 5B, without 
requiring the user to reenter his or her authentication credentials. 
When a disruption or break occurs in the first communication 
session (step 500) between the client 1 08 and the server 41 5, the 
first communication session 41 8 needs to be re-established and the 
client 1 08 re-authenticated to the server 41 5. The ACR Service 405 
provides a system and method for re-establishing and re- 
authenticating the client 1 08 to the server 41 5. 



[01 00] When the client 1 08 and the server 41 5 re-establish a 
second communication session, the client 108 transmits the first 
key and the first SID (step 555) to the server 41 5. The ACR Service 
405 uses the SID (step 558) to locate and retrieve the encrypted 
authentication credentials in the server's memory 430 and uses the 
key (step 560) to decrypt the retrieved authentication credentials. 
The server 41 5 then re-authenticates the client 1 08 to the server 
41 5 (step 565) by validating the authentication credentials from the 
client 108. In one embodiment, the authentication and re- 
authentication is facilitated through the security services provided 
by the operating system of the computing device of the server 41 5. 
For example, the authentication credentials are a login and 
password to the server 41 5. In another embodiment, the 
authentication and re-authentication is facilitated through 
application level security services of an application or software 
program on the server 41 5. For example, the authentication 
credentials are an application login and password to a specific host 
service 1 1 6. 

[01 01 ] To illustrate, upon an abnormal termination of a first 
communication session (step 550) in which the user's login 



password was the authentication credential, the client 108 attempts 
to establish a second communication session with the server 41 5. 
As part of the request to the server 41 5 to establish a second 
communication session with the server 41 5, the client 1 08 
transmits the key and the SID (step 555) of the first terminated 
communication session to the server 41 5. Instead of prompting the 
user to enter the user's login password again, the server 41 5, 
through the ACR Service 405, uses the SID (step 558) to locate and 
retrieve the encrypted authentication credentials associated with the 
user, uses the key (step 560) to decrypt the retrieved authentication 
credentials, and reauthenticates the client using the decrypted 
authentication information (step 565). 

[0102] In one embodiment, during the second 
communication session, the ACR Service 405 creates (step 570) a 
second key for the authentication credentials and then encrypts 
(step 575) the authentication credentials using the second key. A 
second SID is created (step 580) to identify the second 
communication session and associate the session with the client 
1 08. The second encrypted authentication credentials are stored 
(step 525) with the second SID in the table 455. 



[01 03] In this embodiment, the server then transmits (step 
585) the second key and the second SID to the client 1 08. The client 
1 08 then stores (step 590) the second key and the second SID in 
memory (not shown) for future retrieval. The ACR Service 405 then 
deletes (Step 595) the second key from the memory 430. Thus, the 
ACR Service 405 can only decrypt the second encrypted 
authentication upon obtaining the second key and the second SID 
from the client 1 08. The ACR Service 405 has created a new key and 
a new SID for the second communication session that is used with 
the same authentication credentials that the user had transmitted 
during the first communication session. Therefore, a user's 
authentication credentials do not have to be retransmitted upon a 
second communication channel after an abnormal termination of 
the first communication session. 

[0104] Although the invention is discussed in terms of 
authentication credentials, any confidential information which can 
be maintained across sessions if there is a communication failure 
can be used. Thus if credit card information is required by an 
application and the credit card information is sent to the server, the 
subsequent disconnect between the client and the server does not 



require the credit card information to be reentered if this invention 
is issued. Further, although a session identifier, or SID, is discussed 
as providing a pointer to the stored authentication credentials, any 
number or value which is suitable as a pointer may be used. 

[01 05] FIG. 6 depicts another illustrative embodiment of a 
system 600 that is capable of reconnecting a client 1 08 to a server 
41 5 using an ACR Service 405 executing on an intermediary node 
650. The intermediary node 650 is a computing device different 
from the server 41 5 and can be any computing device that is 
capable of communication and that has sufficient processor power 
and memory capacity to perform the operations described herein. 
In brief overview, the client 108 is in communication with an 
intermediary node 650 over a communication channel 41 8. The 
communication channel 41 8 may include a network 1 04. The 
intermediary node 650 provides auto client reconnect services, via 
an ACR Service 405, to the client 1 08 for the connection of the 
client 1 08 to the server 41 5. The intermediary node 650 is in 
communications with the server 41 5 over a communication channel 
41 8. The communication channel 41 8 may include a network 1 04'. 
The client 1 08 accesses the services of the server 41 5 through the 



intermediary node 650. The ACR Service 405 on the intermediary 
node 650 provides auto client reconnect services for the connection 
of the client 1 08 to the server 41 5. Although illustrated with a 
single client 1 08 over a communication channel 41 8, any number of 
clients and number of communication channels can be part of the 
system 600. 

[01 06] In a further embodiment (not shown), the system 600 
includes multiple intermediary nodes 650 that are in 
communication with one or more clients 1 08 through a network 
1 04 over additional communication channels 41 8, 41 8'. Although 
illustrated in FIG. 6 with a single intermediary node 650 over a 
communication channel 41 8, any number of intermediary nodes 
and number of communication channels can part of the system 600. 

[01 07] In another embodiment, the invention relates to 
methods to facilitate establishing and authenticating a clients 108 
connection to a server 41 5 using one or more intermediary nodes 
650. As shown in FIG 7A, an intermediary node 650 establishes 
(step 520A) a session with the server 41 5. 

[01 08] The client 1 08 establishes a first communication 
session with the intermediary node 650 over the communication 



channel 41 8. The client 1 08 obtains (step 500) authentication 
credentials from a user of the client 1 08. The client 1 08 then 
transmits (step 505) the authentication credentials to the 
intermediary node 650 over the communication channel 41 8 so that 
the intermediary node 650 can authenticate the user with the server 
41 5. 

[01 09] After the intermediary node 650 receives the 
authentication credentials, the ACR Service 405 provides its auto 
client reconnect services. The ACR Service 405 creates (step 51 0) a 
first encryption key for use with the authentication credentials and 
then encrypts (step 51 5) the authentication credentials with the first 
key to generate encrypted authentication credentials. This prevents 
an attacker who gains access to the server 41 5 from accessing the 
authentication credentials without the key. Then a session is 
established with the server 41 5 (step 520A) and the client 1 08 is 
authenticated to the server 41 5 using the authentication 
credentials. Thereby, the ACR Service 405 creates a first SID to 
identify the first communication session. The encrypted 
authentication credentials are stored (step 525) with the first SID in 
the table 455 described above. The intermediary node 650 then 



transmits (step 535) the first key and the first SID to the client 1 08 
over the network 1 04. The client 1 08 stores (step 540) the first key 
and the first SID in the clients 1 08 memory (not shown). The ACR 
Service 405 then deletes (step 545) the key stored in memory 430. 

[01 1 0] Once the client 1 08 receives the first key and the first 
SID from the intermediary node 650 as described above in reference 
to FIG. 7A, the communication session can be re-established and 
re-authenticated, as shown in FIG. 7B, without requiring the user to 
reenter his or her authentication credentials. For example, there 
may be a disruption in the first communication session (step 705) 
between the client 1 08 and the intermediary node 650 from an 
abnormal termination. 

[0111] When the client 1 08 and the intermediary node 650 
re-establish a second communication session, the client 108 
transmits the first key and the first SID (step 555) to the 
intermediary node 650. The ACR Service 405 of the intermediary 
node 650 uses the SID (step 558) to locate and retrieve the 
encrypted authentication credentials in the server's memory 430 and 
uses the key (step 560) to decrypt the retrieved authentication 
credentials. The key generator creates (step 570) a second key for 



the authentication credentials and the key encryptor 440 then 
encrypts (step 575) the authentication credentials using the second 
key. The SID generator 438 also creates (step 580) a second SID to 
identify the second communication session and associates it with 
the maintained session between the intermediary node 650 and the 
server 41 5. The encryptor 440 stores the second encrypted 
authentication credentials with the second SID in the table 455. 

[01 1 2] In this embodiment, the server 41 5 then transmits 
(step 585) the second key and the second SID to the client 1 08. The 
client 1 08 then stores (step 590) the second key and the second SID 
for future retrieval. The key destroyer 445 then deletes (Step 595) 
the second key from the memory 430. Thus, the ACR Service 405 
can only decrypt the second encrypted authentication upon 
obtaining the second key and the second SID from the client 1 08. 
The ACR Service 405 has created a new key and a new SID for the 
second communication session that is used with the same 
authentication credentials that the user had transmitted during the 
first communication session. Therefore, a user's authentication 
credentials do not have to be retransmitted upon a second 



communication channel after an abnormal termination of the first 
communication session. 

[01 1 3] In another embodiment, there may be a disruption or 
abnormal termination in the second communication session (step 
71 0) between the intermediary node 650 and the server 41 5. As 
described in FIG. 7C, the second communication session can be re- 
established and re-authenticated without requiring the user to 
reenter his or her authentication credentials. 

[01 1 4] When the intermediary node 650 and the server 41 5 
re-establish a second communication session, the intermediary 
node 650 requests (step 550) the first key and first SID from the 
client 1 08 to re-establish a session with the server 41 5 on the 
clients behalf. In response, the client 1 08 transmits the first key and 
the first SID (step 555) to the intermediary node 650. The ACR 
Service 405 of the intermediary node 650 uses the SID (step 558) to 
locate and retrieve the encrypted authentication credentials in the 
server's memory 430 and uses the key (step 560) to decrypt the 
retrieved authentication credentials. The ACR Service 500 then re- 
establishes the clients session with the server (step 565) using the 



decrypted authentication credentials to re-authenticate the client 
1 08 to the server 41 5. 

[01 1 5] In another embodiment, after re-establishing and re- 
authenticating the client over the second communication session, 
the ACR Service 405 of the intermediary node 650 creates a 
replacement second SID and second key as previously described in 
FIG. 7B. In reference to the embodiment of the ACR Service 
illustrated in FIG 4, the key generator creates (step 570) a second 
key for the authentication credentials and the key encryptor 440 
then encrypts (step 575) the authentication credentials using the 
second key. The SID generator 438 also creates (step 580) a second 
SID to identify the second communication session and associates it 
with the re-established session between the intermediary node 650 
and the server 41 5. The encryptor 440 stores the second encrypted 
authentication credentials with the second SID in the table 455. In 
this embodiment, the server then transmits (step 585) the second 
key and the second SID to the client 1 08. The client 1 08 then stores 
(step 590) the second key and the second SID for future retrieval. 
The key destroyer 445 then deletes (Step 595) the second key from 
the memory 430. 



[01 1 6] In other embodiments, one or more of the first 
protocol service 1 1 2 and ACR Service 405 can be distributed across 
any of the host service nodes. As such, the functionality of re- 
establishing and re-authenticating, or automatically reconnecting, a 
client 1 08 connect to a host service 1 1 6 can be flexibly distributed 
in different system and deployment architectures across host 
services 1 1 6 and/or host nodes 1 1 8. 

[01 1 7] In one embodiment of this aspect of the invention, an 
ACR Service 405 can be associated with each of the host services 
1 1 6a-l 1 6n in system 1 00 to provide auto client reconnect services 
dedicated to each host service 1 16, respectively. A single first 
protocol service 1 1 2 can be deployed to handle all of the host 
services 1 1 6a-l 1 6n. As shown in Fig 8A, each of the multiple ACR 
Services 405a-405n is associated with each of the host services 
1 1 6a-l 1 6n, respectively. By way of example, a client 1 08 
establishes a communication session with the host service 1 1 6a 
using the first protocol service 1 1 2. The ACR Service 405a 
associated with host service 1 1 6a provides auto client reconnect 
services for the connection of the client 1 08 to the host service 
1 16a. If there is a disruption in a network connection, the first 



protocol service 1 1 2 will re-establish the connection with the client 
1 08 and the ACR Service 405a will re-authenticate the client 1 08 to 
the host service 1 1 6a. A second client 1 08' may concurrently, with 
the first client 108, establish a communication session with the host 
service 1 1 6b using the first protocol service 1 1 2. The ACR Service 
405b provides auto client reconnect services for the client's 
connection to the host service 1 16b. If there is a network 
disruption, the first protocol service 1 1 2 in conjunction with the 
ACR Service 405b will reconnect the client 1 08" to the host service 
1 16b. 

[01 1 8] In another embodiment of this aspect of the 
invention, an ACR service can be associated with each of the 
multiple host services 1 1 6a-l 1 6n running on each of the host 
nodes 1 1 8a- 1 1 8n of the system 1 00. A first protocol service 1 1 2 
can be deployed on each host node 1 1 8 to service each of the 
multiple host services 1 1 6a-l 1 6n running on that host node 1 1 8. 
As shown in Fig. 8B, each ACR service 405a-405n is associated with 
each host service 1 1 6a-l 1 6n, respectively. Each host node 1 1 8 has 
a dedicated first protocol service 1 1 2 servicing each of its host 
services 1 1 6 and each ACR Service 405. For example, a client 1 08 



establishes a communication session with host service 1 16a on host 
node 1 1 8a by using the first protocol service 1 1 2a. The ACR Service 
405a on host node 1 1 8a provides auto client reconnect services for 
the connection of the client 1 08 to the host service 1 1 6a on host 
node 1 1 8a. 

[01 19] If a network disruption is detected, the first protocol 
service 1 1 2a re-establishes the client's connection to the host 
service 1 1 6a on host node 1 1 8a and the ACR service 405a on host 
node 1 1 8a re-authenticates the client 1 08 to the host service 1 1 6a 
on host node 1 1 8a. Concurrently with the first client 1 08, a second 
client 108? establishes a communication session with host service 
1 1 6b on host node 1 1 8a using the first protocol service 1 1 2a and 
ACR Service 405a. If there is a network disruption, the first protocol 
service 1 1 2a in conjunction with the ACR Service 405a reconnect 
the client 1 08" with host service 1 1 6b on host node 1 1 8a. 
Concurrently with the first client 1 08 and the second client 1 08', a 
third client 1 08'establishes a communication session with host 
service 1 1 6n on host node 1 1 8b using the first protocol service 
1 1 2b and ACR Service 405n on host node 1 1 8b. In a similar 
manner, the first protocol service 1 1 2b and ACR Service 405n can 



reconnect the client 1 08* to the host service 1 1 6n of host node 
1 18b. 

[01 20] In other embodiments, one or more of the ACR 
Services 405 can be distributed with the first protocol services 1 1 2 
across any of the intermediary or first protocol services nodes. As 
such, the functionality of reconnecting a client 1 08 to a host service 
1 1 6 can be flexibly distributed in different system and deployment 
architectures associated with the first protocol service 1 1 2. 

[0121] In one embodiment of this aspect of the invention, 
the ACR Service 405 can be associated with each first protocol 
service 1 1 2 to provide auto client reconnect services dedicated to 
the first protocol service 1 1 2. A single first protocol service 1 1 2 and 
ACR Service 405 can be deployed to handle all of the host services 
1 1 6a-l 1 6n. As shown in Fig 9A, the ACR Service 405 resides with 
the first protocol service 1 1 2 on the same computing device to 
provide auto client reconnect services to host services 1 1 6a-l 1 6n. 
For example, a client 1 08 establishes a communication session with 
any of the host services 1 1 6a-l 1 6n by using the first protocol 
service 1 1 2 and ACR Service 405. The first protocol service 1 1 2 and 



ACR Service 405 provide reconnecting functionality from a client 

I 08 to any of the host services 1 1 6a-l 1 6n. 

[01 22] In another embodiment of this aspect of the 
invention, each of the ACR Services 405a-405n can be associated 
with each of the multiple of first protocol services 1 16a-l 16n. For 
example as shown in Fig. 9B, a first protocol service 1 1 2a and an 
ACR Service 405a can be deployed on a host node 1 1 8a to service 
each of the multiple host services 1 16a-l 16n running on that host 
node 1 1 8a. As further shown in Fig. 9B, each ACR service 405a- 
405n is associated with each first protocol service 1 1 2a- 1 1 2n to 
provide dedicated auto client reconnect services to the multiple host 
services 1 1 6a- 1 1 6n of each host node 1 1 8a- 1 1 8n. By way of 
example, client 108 establishes a communication session with host 
service 1 1 6a on host node 1 1 8a by using the first protocol service 

I I 2a and ACR Service 405a on the same host node 1 1 8a. If there is 
a network disruption, the first protocol service 1 1 2a in conjunction 
with the ACR Service 405a reconnects the client 1 08 to the host 
service 1 1 6a on the host node 1 1 8a. 

[01 23] Although the invention is discussed above in terms of 
various system and deployment architectures in FIGS. 8A-8B and 



9A-9B, any other system and/or deployment architecture that 
combines and/or distributes one or more of the first protocol 
service(s) 1 1 2, ACR Service(s) 405, and host service(s) 1 1 6 across 
any of the host nodes 1 1 8, intermediary nodes 650 or other 
computing devices can be used. 

[01 24] Furthermore, instead of using an ACR Service 405 to 
provide authentication and re-authentication services, a ticket 
authority 1 036 service can be used. A ticket authority 1 036 
generates and validates tickets for connection and authentication 
purposes. A ticket can comprise a session identifier and key. It can 
also comprise a random number, an application server certificate, a 
nonce, a constant or null value or any other type of identification, 
confidential or security based information that may be used for 
such purposes. 

[01 25] In an embodiment of a network communication 
system 1 000 for reconnecting a client 1 08 to a host service 1 1 6 as 
shown in Fig 1 OA, a ticket authority 1 036 can run on a node 
separate from the intermediary node 1032, first protocol service 
1 1 2 or any of the host services 1 1 6a-l 1 6n. Fig 1 OA depicts an 
intermediary node 1 032 and ticket authority 1 036, which could be a 



single computing device, as part of the system 1000. In addition to 
the networks 1 04 and 1 04', the system 1 000 includes a client 1 08, 
first protocol service 1 1 2, and the host services 1 1 6a-l 1 6n, all of 
which are described above. In one embodiment, the intermediary 
node 1 032 is a security gateway, such as, for example, a firewall 
and/or a router, through which messages between the client 1 08 
and the first protocol service 1 1 2 must pass due to the 
configuration of the network 104. The ticket authority 1036 can be, 
for example, a stand-alone network component that is capable of 
communication and that has sufficient processor power and 
memory capacity to perform the operations described herein. The 
ticket authority 1 036 also can be a specific host service 1 1 6 
dedicated to providing ticket related services on a server 41 5. 

[01 26] As shown in the illustrative embodiment of FIG. 1 OA, 
the intermediary node 1 032 is configured to accept a connection 
1 20a initiated by the client 1 08 and to establish a second 
connection 1 20b with the first protocol service 1 1 2. Together, the 
connection 1 20a and the second connection 1 20b constitute the 
connection 1 20, described above, over which the client 1 08 and the 
first protocol service 1 1 2 communicate using the first protocol. 



[01 27] The intermediary node 1 032, as shown, is also 
configured to communicate with the ticket authority 1 036. In one 
embodiment, the ticket authority 1036 is configured to receive a 
request for a first reconnection ticket from the intermediate node 
1 032 and to thereafter generate the first reconnection ticket. The 
first reconnection ticket can include, for example, a large random 
number. The first reconnection ticket allows the client 1 08 to 
automatically re-establish a connection with the host service after 
an abnormal disruption of service without requiring the client 1 08 
to provide authentication credentials again. 

[01 28] After generation of the first reconnection ticket, the 
ticket authority 1036 encrypts the authentication credentials 
supplied by the client 1 08 using the first reconnection ticket so that 
an attacker who gains access to the intermediary node 1 032 or the 
ticket authority 1036 cannot access the authentication credentials 
without the first reconnection ticket. The ticket authority 1 036 may 
also generate a SID to identify the communication session that is 
established between the client 1 08 and the intermediary node 1 032. 
The ticket authority 1 036 then stores the encrypted authentication 
credentials with the SID in memory and transmits the SID and the 



first reconnection ticket to the client 1 08 over the network 1 04. 
Upon the client's receipt of the SID and the first reconnection ticket, 
the ticket authority 1 036 destroys (i.e., deletes) the ticket from its 
memory (not shown). 

[01 29] In another embodiment, the ticket authority 1 036 is 
configured to generate a handle. The handle can be, for example, a 
random number that is associated with {e.g., mapped to) the first 
reconnection ticket. In one embodiment, the handle is a smaller 
random number than the random number forming the first 
reconnection ticket. For example, the handle may be a 32-bit 
random number. The ticket authority 1 036 transmits the first 
reconnection ticket and the handle to the intermediary node 1 032, 
while keeping a copy of the first reconnection ticket and a copy of 
the handle. The copy of the first reconnection ticket can later be 
used by the ticket authority 1 036 to validate the first reconnection 
ticket originally transmitted to the client 1 08 when it is later 
presented to the ticket authority 1036 during the process of 
reconnecting the client 1 08. In one embodiment, the ticket 
authority 1 036 also keeps an address for the first protocol service 
1 1 2, which, as explained below, is associated with the first 



reconnection ticket and, upon validation of the first reconnection 
ticket, is transmitted to the intermediary node 1032. 

[01 30] In one embodiment, the intermediary node 1 032 is 
further configured to use the handle transmitted to it by the ticket 
authority 1 036 to delete the copy of the first reconnection ticket 
kept at the ticket authority 1 036. In another embodiment, as 
described below, the ticket authority 1 036 is further configured to 
delete, during the process of reconnecting the client 1 08 to a host 
service 1 1 6, the first reconnection ticket and thereafter generate a 
replacement first reconnection ticket. Additionally, in another 
embodiment, the first reconnection ticket is configured for 
automatic deletion after a pre-determined period of time. 

[0131] In another embodiment, the first protocol service 1 1 2 
is configured to generate a second reconnection ticket, which, as in 
the case of the first reconnection ticket, can include, for example, a 
large random number. The first protocol service 1 12 can also be 
configured to transmit the second reconnection ticket to the client 
1 08, while keeping a copy of the second reconnection ticket and a 
session number. The copy of the second reconnection ticket can 
later be used by the first protocol service 1 1 2 to validate the second 



reconnection ticket originally transmitted to the client 1 08 when it 
is later presented to the first protocol service 1 1 2 during the 
process of reconnecting the client 1 08. In one embodiment, the 
first protocol service 1 1 2 transmits the second reconnection ticket 
to the client 1 08 via the intermediary node 1 032. In another 
embodiment, the first protocol service 1 1 2 transmits the second 
reconnection ticket to the client 1 08 directly. Moreover, as 
described in greater detail below, the first protocol service 1 1 2 can 
be further configured to delete, during the process of reconnecting 
the client 1 08 to a host service 1 1 6, the second reconnection ticket, 
and thereafter generate a replacement second reconnection ticket. 
Additionally, in another embodiment, the second reconnection 
ticket is configured for automatic deletion after a pre-determined 
period of time. 

[01 32] In one embodiment, the intermediary node 1 032 
serves as an intermediary for the first and second reconnection 
tickets. The intermediary node 1032 receives, for example, the first 
reconnection ticket generated by the ticket authority 1 036 and the 
second reconnection ticket generated by the first protocol service 
1 1 2. The intermediary node 1 032 can then transmit the first 



reconnection ticket and the second reconnection ticket to the client 
1 08. Moreover, during the process of reconnecting the client 1 08 
to a host service 1 1 6, the intermediary node 1 032 can accept the 
first reconnection ticket and the second reconnection ticket from 
the client 1 08 and thereafter transmit the first reconnection ticket 
to the ticket authority 1 036 and, if appropriate, the second 
reconnection ticket to the first protocol service 1 1 2. 

[01 33] If the first communication session between the client 
1 08 and the host service 1 1 6 terminates, for example abnormally, 
the new session can be re-established without requiring the user to 
reenter his or her authentication credentials. When the client 1 08 
and the host service 1 16 re-establish a second communication 
session, the client 1 08 retransmits the first and second 
reconnection tickets and the SID to the intermediary node 1 032. 
The intermediary node 1 032 transmits the first and second 
reconnection tickets and the SID to the ticket authority 1 036, which 
uses the SID to locate and retrieve the encrypted authentication 
credentials for the first connection and uses the first reconnection 
ticket to decrypt the retrieved authentication credentials. The ticket 
authority 1036 then authenticates the client by validating the 



decrypted authentication credentials. After re-authentication, the 
second reconnection ticket is forwarded to the first protocol service 
1 1 2 to re-establish the second connection 1 24 with the host service 
116. 

[01 34] In another embodiment of a network communications 
system 1 000 as shown in FIG. 1 OB, an ACR Service 405 can be used 
instead of the ticket authority 1036 for reconnecting the client 108 
to any of the host services 1 1 6a-l 1 6n. In this embodiment, the 
ACR Service 405 can provide similar services as described above 
with regards to the ticket authority 1 036. As previously described, 
the ACR Service 405 generates, validates and manages a SID and a 
key for connecting and reconnecting a client communication 
session. A SID and a key can form a ticket as in the type of ticket 
generated, validated and managed by the ticket authority 1 036 as 
described above. As such, in another embodiment, a ticket may be 
used interchangeably for the combination of a session identifier and 
a key. 

[0135] The intermediary node 1032, as shown in FIG. 1 0B, is 
configured to communicate with the ACR Service 405. In one 
embodiment, the ACR Service 405 is configured to receive a request 



for a first SID and a first key from the intermediary node 1 032 and 
to thereafter generate the first SID and first key. The ACR Service 
405 uses the first SID to identify the communication session that is 
established between the client 1 08 and a host service 1 1 6. The first 
SID and the first key allow the client 1 08 to automatically reconnect 
with the host service 1 1 6 after an abnormal disruption of service 
without requiring the client 108 to provide authentication 
credentials again. 

[01 36] After generation of the first SID and the first key, the 
ACR Service 405 encrypts the authentication credentials supplied by 
the client 1 08 using the first key so that an attacker who gains 
access to the intermediary node 1 032 or the ACR Service 405 
cannot access the authentication credentials without the first key. 
The ACR Service 405 then stores the encrypted authentication 
credentials with the SID in memory 430 and transmits the first SID 
and the first key to the client 1 08 over the network 1 04. Upon the 
client's receipt of the SID and the key, the ACR Service 405 destroys 
(i.e., deletes) the key from its memory 430. 

[01 37] In another embodiment, the first protocol service 1 1 2 
is configured to generate a second SID and second key. The first 



protocol service 1 1 2 can also be configured to transmit the second 
SID and second key to the client 1 08, while keeping a copy of the 
second SID and second key. The copy of the second SID and second 
key can later be used by the first protocol service 1 1 2 to validate 
the second SID and second key originally transmitted to the client 
1 08 when it is later presented to the first protocol service 1 1 2 
during the process of reconnecting the client 1 08. In one 
embodiment, the first protocol service 1 1 2 transmits the second SID 
and second key to the client 1 08 via the intermediary node 1 032. 
In another embodiment, the first protocol service 1 1 2 transmits the 
second SID and second key to the client 1 08 directly. Moreover, as 
described in greater detail below, the first protocol service 1 1 2 can 
be further configured to delete, during the process of reconnecting 
the client 1 08 to a host service 1 1 6, the second SID and second key, 
and thereafter generate a replacement second SID and second key. 
Additionally, in another embodiment, the second SID and second 
key is configured for automatic deletion after a pre-determined 
period of time. 

[01 38] In one embodiment, the intermediary node 1 032 
serves as an intermediary for the first and second SIDs and keys. 



The intermediary node 1 032 receives, for example, the first SID and 
first key generated by the ACR Service 405 and the second SID and 
second key generated by the first protocol service 1 1 2. The 
intermediary node 1 032 can then transmit the first SID and first key 
and the SID and second key to the client 1 08. Moreover, during the 
process of reconnecting the client 1 08 to a host service 1 1 6, the 
intermediary node 1 032 can accept the first SID and first key and 
the second SID and second key from the client 1 08 and thereafter 
transmit the first SID and first key to the ACR Service 405 and, if 
appropriate, the second SID and second key t to the first protocol 
service 1 1 2. 

[01 39] If the first communication session between the client 
1 08 and the host service 1 1 6 terminates, for example abnormally, 
the new session can be re-established without requiring the user to 
reenter his or her authentication credentials. When the client 1 08 
and the host service 1 16 re-establish a second communication 
session, the client 1 08 transmits the first and second SIDs and keys 
to the intermediary node 1 032. The intermediary node 1 032 
transmits the first SID and first key to the ACR Service 405, which 
uses the SID to locate and retrieve the encrypted authentication 



credentials for the first connection and uses the first key to decrypt 
the retrieved authentication credentials. The ACR Service 405 then 
authenticates the client by validating the decrypted authentication 
credentials. After re-authentication, the second SID and second key 
is forwarded to the first protocol service 1 1 2 to re-establish the 
second connection 1 24 with the host service 1 16. 

[0140] Referring to FIG. 1 1A, another embodiment of a 
system 1 1 00 for network communications includes the networks 

I 04 and 1 04', the client 1 08, the first protocol service 1 1 2, the host 
services 1 1 6, the intermediary node 1 032, and the ticket authority 

1 036, as described above, and further depicts a first computing 
node 1 140 and a second computing node 144, both of which are 
used, in one embodiment, for initially connecting the client 1 08 to a 
host service 1 16. Moreover, in the illustrative embodiment of FIG. 

I I A, the client 1 08 further includes a web browser 1 48, such as, for 
example, the INTERNET EXPLORER program from Microsoft 
Corporation of Redmond, WA, to connect to the World Wide Web. 

[0141] In one embodiment (not shown), the system 1 1 00 
includes two or more intermediary nodes 1 032 and/or two or more 
first protocol services 1 1 2. The intermediary node 1 032, through 



which messages between the client 108 and the first protocol 
service 1 1 2 must pass, and/or the first protocol service 1 1 2 can, as 
explained below, each be chosen based on, for example, a load 
balancing equation. 

[0142] Each of the first computing node 1 140 and the 
second computing node 1 144 can be any computing device that is 
capable of communication and that has sufficient processor power 
and memory capacity to perform the operations described herein. 
For example, in one embodiment, the first computing node 1 140 is 
a web server, providing one or more websites or web based 
applications. In another embodiment, the second computing node 
1 1 44 provides an XML service or web service. 

[01 43] In one embodiment, the client 1 08 and the network 

I 04 form an external network 1 1 52, separated from the rest of the 
system 1 1 00 by a first firewall 1 1 56, depicted as a dashed line. The 
intermediary node 1032 and the first computing node 1 140 can be 
located in a "demilitarized zone" 1 1 60 {i.e., a network region placed 
between a company's private network and the public network), 
separated from the rest of the system 1 1 00 by the first firewall 

I I 56 and a second firewall 1 1 64, also depicted by a dashed line. 



Then, as shown, the network 1 04', the first protocol service 1 1 2, the 
host services 1 1 6a-l 1 6n, the ticket authority 1 036, and the second 
computing node 1 144, form an internal network 1 1 68, separated 
from the rest of the system 1 1 00 by the second firewall 1 1 64. 

[0144] Alternatively, in another embodiment not shown in 
FIG. 1 1 A, the system 1 1 00 further includes a third computing node 
1 146 positioned, in the demilitarized zone 1 160, between the 
network 1 04 and the intermediary node 1 032. The third computing 
node 1 1 46 can be any computing device that is capable of 
networked communication and that has sufficient processor power 
and memory capacity to perform the operations described herein. 
As described below, the third computing node 1 146 is used, in 
some embodiments, during the process of initially connecting the 
client 1 08 to a host service 1 1 6 and/or during the process of 
reconnecting the client 1 08 to a host service 1 1 6. More specifically, 
as described below, where the system 1 1 00 includes two or more 
intermediary nodes 1 032, the third computing node 1 1 46 can, 
based on a load balancing equation for example, choose the 
intermediary node 1032 through with communications between the 



client agent 1 28 of the client 1 08 and the first protocol service 1 1 2 
must pass. 

[0145] Moreover, referring to FIG. 1 1A, the intermediary 
node 1032, in an alternative embodiment, can be replaced by two or 
more levels "a-'n" of intermediary nodes 1032. As illustrated, each 
level "cl-if can include two or more intermediary nodes 1032a- 
1 032n. As described below, the client agent 1 28 of the client 1 08 
can be routed through any combination of the intermediary nodes 
1032 based on, for example, load balancing equations. For 
example, as illustrated, the client agent 1 28 can be routed through 
the intermediary nodes 1 032 via connection 1 20. Other 
configurations of the system 1 1 00, as would be readily apparent to 
one skilled in the art, are also possible. 

[0146] Referring again to FIG. 1 1A, in one embodiment, the 
web browser 1 148 communicates over the network 1 04 with the 
first computing node 1 140, which itself interfaces with the second 
computing node 1 1 44 and the ticket authority 1 036. More 
specifically, the first computing node 1 140 is configured with the 
address of the second computing node 1 144 and the ticket 
authority 1036. In one embodiment, as explained further below, 



the first computing node 1 140 is configured to relay information 
between, and thereby prevent direct communication between, the 
web browser 1 148 of the client 108, the second computing node 
1 1 44, and the ticket authority 1 036. By preventing such direct 
communication, the first computing node 1 140 adds an additional 
level of security to the system 1 1 00. The first computing node 
1 140 can also be configured with the address of the intermediary 
node 1032, or, alternatively, with the address of two or more 
intermediary nodes 1032. 

[0147] For its part, the second computing node 1 144 is 
configured to determine which of the application programs running 
on the host services 1 1 6 are available to a user of the client 1 08. In 
other words, the second computing node 1 144 is configured to 
determine which of the application programs the user is authorized 
to access. In one embodiment, after the user selects his desired 
application program, as described further below, the second 
computing node 1 144 is further configured to determine which of 
the host services 1 1 6 will be used to run the user's desired 
application for purposes of load balancing. The second computing 
node 1 1 44 returns the address of that host service 1 1 6 to the first 



computing node 1 140. The second computing node 1 144 also 
returns the address of the first protocol service 1 1 2, which can also 
be selected from amongst a plurality of first protocol services 1 1 2 
through the use of a load balancing equation, to the first computing 
node 1 1 40. In turn, the first computing node 1 1 40 transmits the 
address of the chosen first protocol service 1 1 2 and the chosen 
host service 1 1 6 to the ticket authority 1 036. 

[01 48] For its part, the ticket authority 1 036 generates 
connection tickets. In one embodiment, the ticket authority 1 036 
transmits an initial connection ticket to the first computing node 
1 1 40 for transmission to the client 1 08. In another embodiment, 
the ticket authority transmits a first reconnection ticket to the 
intermediary node 1032. 

[01 49] In another embodiment of a network communication 
system 1 1 00 as shown in FIG. 1 1 B, the ACR Service 405 can be used 
instead of the ticket authority 1 036 to reconnect a client 1 08 to a 
host service 1 1 6. Instead of using tickets as with the ticket 
authority 1 036, the ACR Service 405 generates, validates and 
manages SIDs and keys for connecting and reconnecting client 
communication sessions. The ACR Service 405 authenticates and 



re-authenticates the client to a host service 1 1 6 or server 41 5 using 
a SID and key, or a ticket, associated with the client 1 08. As 
previously mentioned, a ticket can be used to refer to the 
combination of a SID and key or a ticket can comprise a SID and a 
key. 

[01 50] The system 1 1 00 of FIG. 1 1 B includes the networks 
1 04 and 1 04', the client 1 08, the first protocol service 1 1 2, the host 
services 1 1 6, the intermediary node 1 032, and the ACR Service 405, 
as described above, and further depicts a first computing node 
1 140 and a second computing node 144, both of which are used, in 
one embodiment, for initially connecting the client 1 08 to a host 
service 1 1 6. Moreover, the client 1 08 further includes a web 
browser 1 48 to connect to the World Wide Web. 

[01 51 ] In one embodiment (not shown), the system 1 1 00 
includes two or more intermediary nodes 1 032 and/or two or more 
first protocol services 1 1 2 or two or more ACR Services 405. The 
intermediary node 1032, through which messages between the 
client 1 08 and the first protocol service 1 1 2 must pass, and/or the 
first protocol service 1 1 2 can and/or the ACR Service 405, as 



explained below, each be chosen based on, for example, a load 
balancing equation. 

[01 52] In another embodiment, the system 1 1 00 of FIG. 1 1 B 
can include an external network 1 1 52, separated from a 
'demilitarized zone" 1 1 60 by a first firewall 1 1 56 which in turn is 
separated from an internal network 1 1 68 by a second firewall 1 1 64. 
Although the invention is discussed above in terms of various 
network topologies in FIGS. 1 1A and 1 1 B, any other network 
topologies can be used, such as for example, a topology including 
combinations of internal networks, external networks, sub- 
networks, intranets, firewalls, security zones, single servers, a 
server network or server farms. 

[01 53] Alternatively, in another embodiment not shown in 
FIG. 1 1 B, the system 1 1 00 further includes a third computing node 
1 146 positioned, in the demilitarized zone 1 160, between the 
network 1 04 and the intermediary node 1 032. The third computing 
node 1 146 is used, in some embodiments, during the process of 
initially connecting the client 1 08 to a host service 1 1 6 and/or 
during the process of reconnecting the client 1 08 to a host service 
116. 



[01 54] In another embodiment of the system 1 1 00 in FIG. 
1 1 B, the intermediary node 1 032, can be replaced by two or more 
levels "el-Vf of intermediary nodes 1 032a-l 032n. The client agent 
1 28 of the client 1 08 can be routed through any combination of the 
intermediary nodes 1032 based on, for example, load balancing 
equations. 

[01 55] In one embodiment, the web browser 1 1 48 
communicates over the network 1 04 with the first computing node 
1 1 40, which itself interfaces with the second computing node 1 1 44 
and the ACR Service 405. The first computing node 1 1 40 is 
configured with the address of the second computing node 1 144 
and the ACR Service 405. In another embodiment to provide an 
additional level of security in the system 1 1 00, the first computing 
node 1 140 is configured to relay information between, and thereby 
prevent direct communication between, the web browser 1 148 of 
the client 1 08, the second computing node 1 1 44, and the ACR 
Service 405. The first computing node 1 140 can also be configured 
with the address of any of the intermediary nodes 1 032a-l 032n. 

[01 56] For its part, the second computing node 1 144 is 
configured to determine which of the application programs running 



on the host services 1 1 6 are available to a user of the client 1 08 
and to provide the address of the host service 1 16 selected by the 
user to the first computing node 1 1 40. The second computing 
node 1 144 also provides the address of one of the multiple first 
protocol service 1 12, through the use of a load balancing equation, 
to the first computing node 1 140. In turn, the first computing node 
1 140 transmits the address of the chosen first protocol service 1 1 2 
and the chosen host service 1 1 6 to the ACR Service 405. 

[01 57] For its part, the ACR Service 405 generates, validates 
and manages connection SIDs and key to provide authentication and 
re-authentications services to re-establish a client's communication 
session with a host service 1 1 6 or server 41 5, as described herein. 
In one embodiment, the ACR Service 405 transmits a first SID and 
first key to the first computing node 1 1 40 for transmission to the 
client 1 08. In another embodiment, the ACR Service 405 transmits 
a first SID and first key to one of the intermediary nodes 1 032. 

[01 58] In another aspect, this invention relates to methods 
for network communications and reconnecting a client 1 08 to a 
host service 1 1 6 using a plurality of secondary protocols 
encapsulated within a first protocol. The method includes 



establishing a first connection between a client 1 08 and a first 
protocol service 1 1 2 using a first protocol and communicating 
between the client 1 08 and the first protocol service 1 1 2 via a 
plurality of second protocols encapsulated within the first protocol. 
Moreover, at least one of the second protocols includes a plurality 
of virtual channels. 

[01 59] In one embodiment of this aspect of the invention, a 
second connection is established between the first protocol service 
1 1 2 and a host service 1 1 6 using one of the secondary protocols. 
Communication between the first protocol service 1 12 and the host 
service 1 1 6 occurs via one of the secondary protocols. Specifically, 
each of the plurality of second connections is established between 
the first protocol service 1 1 2 and a different host service 1 1 6 and 
each of the plurality of second connections is established using one 
of the plurality of secondary protocols. In yet another embodiment, 
the first connection between the client 1 08 and the first protocol 
service 1 1 6 is established through one or more intermediary nodes 
1032. 

[01 60] Referring now to FIG. 1 2A, one embodiment of a 
method 1 200 for reconnecting a client to a host service after a 



network failure is illustrated. At step 1 204, the client 1 08 initially 
connects to one of a plurality of host services 1 1 6 by employing, for 
example. Generally, the client 108 is required to transmit 
authentication credentials to the host service 1 1 6 to initiate the 
communication session. After the client 1 08 is connected to the 
host service 1 1 6, the client 1 08 and the host service 1 1 6 
communicate, through the first protocol service 1 1 2, and at step 
1 208, via a plurality of secondary protocols encapsulated within the 
first protocol as discussed above in reference to FIGS. 2A-2B and 
FIG. 3. In one embodiment, the first protocol service 1 1 2 encrypts, 
prior to the transmission of any first protocol packets, 
communications at the level of the first protocol 204, thereby 
securing the communications. In another embodiment, the first 
protocol service 1 1 2 compresses, prior to the transmission of any 
first protocol packets, the communications at the level of the first 
protocol, thereby improving communication efficiency. 

[01 61 ] At step 1212, the client agent 1 28 determines 
whether the connection 1 20 between the client agent 1 28 and the 
first protocol service 1 1 2 has failed. For example, the connection 
1 20a between the client agent 1 28 and the intermediary node 1 032 



may have failed, the connection 1 20b between the intermediary 
node 1 032 and the first protocol service 1 1 2 may have failed, or 
both the connection 1 20a and the connection 1 20b may have failed. 
If the client agent 1 28 determines that the connection 1 20 has not 
failed, the method 1 200 proceeds to step 1 220. If, on the other 
hand, the client agent 1 28 determines that the connection 1 20 has 
failed, the client 1 08 is, at step 1 21 6, reconnected to the host 
service 1 1 6. 

[01 62] The step of reconnecting in step 1216 after a first 
communication session ends abnormally, can comprise in a system 
1 1 00 deploying a ticket authority 1 036 and the client 1 08 
transmitting the SID and the first and second reconnection tickets to 
the intermediary node 1 032. The intermediary node 1 032 uses the 
first reconnection ticket to authenticate the client 1 08 and re- 
establish the connection 1 20 between the client 1 08 and the 
intermediate node 1032. The intermediary node 1032 then 
transmits the second reconnection ticket to the first protocol service 
1 1 2, which uses the second reconnection ticket to authenticate re- 
establish the connection 1 24 to the host service 1 1 6. The 
reconnection tickets thus allow the client 1 08 to automatically 



establish a second communication session to the host service 1 16 
without retransmitting the authentication credentials a second time. 

[01 63] In another embodiment, the step of reconnecting, in 
step 1216, can also comprise a system 1 1 00 deploying an ACR 
Service 405. In such an embodiment, the client 1 08 transmits a first 
SID and first key to the intermediary node 1 032 to authenticate the 
client 1 08 and reestablish the connection of the client 1 08 to the 
host service 1 1 6. 

[01 64] It is determined, at step 1 220, whether the client 1 08 
wishes to cleanly terminate its connection 1 20 with the first 
protocol service 1 1 2 and, consequently, its connections 1 24a-l 24n 
with the host services 1 1 6a-l 1 6n. If not, communication between 
the client 1 08 and the first protocol service 1 1 2, via the plurality of 
secondary protocols encapsulated within the first protocol, 
continues at step 1 208. If so, then, at step 1 224, all connections 
1 20a, 1 20b, and 1 24a-l 24n are broken and all reconnection tickets 
are deleted. In another embodiment using an ACR Service 405, at 
step 1 224, all connections 1 20a, 1 20b, and 1 24a-l 24n are broken 
and all SIDS and keys are deleted. In one embodiment, the 
intermediary node 1 032 uses a handle it receives from the ticket 



authority 1 036 to delete a copy of a first reconnection ticket kept at 
the ticket authority 1 36. In another embodiment deploying a ticket 
authority 1 036, the first protocol service 1 1 2 deletes a copy of a 
second reconnection ticket kept at the first protocol service 112. In 
yet another embodiment deploying the ACR Service 405, the first 
protocol service 1 1 2 deletes a copy of a second SID and second key 
kept at the first protocol service 1 1 2. 

[01 65] In a further embodiment using a ticket authority 
1 036, if for some reason a secondary protocol connection 1 24 fails, 
a copy of the second reconnection ticket associated therewith and 
kept at the first protocol service 1 1 2 is deleted by the first protocol 
service 112. In yet another embodiment, a first reconnection ticket 
and/or a second reconnection ticket is automatically deleted after a 
pre-determined period of time following a failure in the connection 
1 20, as at step 1212, and/or following a clean termination of the 
connection 1 20, as at step 1 220. 

[01 66] In another aspect, this invention relates to methods 
for reconnecting the client 1 08 to the host service 1 1 6 using the 
ACR Service 405. Referring now to FIG. 1 2B, one embodiment of 
the method 1 21 6 to reconnect a client 1 08 to a host service 1 1 6 is 



illustrated. The client 1 08 transmits the first SID and the first key to 
the ACR Service 405 to reconnect to the host service (step 1 255). 
The ACR Service 405 uses the SID (step 1 258) to locate and retrieve 
the encrypted authentication credentials and uses the key (step 

I 260) to decrypt the retrieved authentication credentials. In one 
embodiment (not shown), the ACR Service 405 uses the decrypted 
authentication credentials to re-authenticate the client 1 08 to the 
maintained session between the first protocol service 1 1 3 and the 
host service 1 16. After re-authenticating, the reestablished 
connection of the client 1 08 to the first protocol service 1 1 6 is re- 
linked to the maintained session between the first protocol service 

I I 2 and the host service 1 1 6. 

[01 67] In another embodiment, during the second 
communication session, the ACR Service 405 generates (step 1 270) 
a second key for the authentication credentials and then encrypts 
(step 1 275) the authentication credentials using the second key. 
The ACR Service 405 creates a second SID (step 1 280). Then the 
decrypted authentication credentials are re-authenticated with the 
host service 1 1 6 and the second SID is associated with the 
maintained communication session with the host service 1 16 (step 



1 280a). The ACR Service 405 then transmits the second SID and 
second key to the client 1 08 (step 1 285). In one embodiment, the 
ACR Service 405 may transmit the second SID and second key 
through an intermediary node 1 032. The client 1 08 stores the 
second SID and second key (step 1 290). The ACR Service 405 then 
deletes the second key (step 1 295). 

[01 68] Referring to FIGS. 1 3A-1 3B, one embodiment of a 
method 1 300 for initially connecting the client 1 08 to the host 
service 1 1 6 using an ACR Service 405 is illustrated. At step 1 304, 
the client 108, using the browser 148, sends a request, such as, for 
example, an HTTP request, to the first computing node 1 140. The 
first computing node 1 140 returns a web page, such as, for 
example, an HTML form requesting authentication information {e.g., 
a username and a password). A user of the client 1 08 enters his 
authentication credentials and transmits the completed form to the 
first computing node 1 140. 

[01 69] The first computing node 1 1 40, at step 1 308, then 
informs the user of the client 108 of applications available for 
execution. In one embodiment, the first computing node 1 140 
extracts the user's credentials from the login page and transmits 



them to the second computing node 1 1 44, together with a request 
for the second computing node 1 144 to enumerate the applications 
available to the user. Based on the user's credentials, the second 
computing node 1 1 44 returns a list of specific applications available 
to the first computing node 1 140, which then forwards the list, in 
the form of a web page for example, to the user of the client 1 08. 

[01 70] At step 1312, the user selects the desired application 
and a request for that application is sent to the first computing 
node 1 140. For example, in one embodiment, the user clicks on a 
desired application listed in the web page presented to him by the 
first computing node 1 140 and an HTTP request for that application 
is forwarded to the first computing node 1 140. The request is 
processed by the first computing node 1 40 and forwarded to the 
second computing node 1 144. 

[01 71 ] At step 1316, the second computing node 1 44 
determines the host service 1 1 6 on which the desired application 
will be executed. The second computing node 1 144 can make that 
determination based, for example, on a load balancing equation. In 
one embodiment, the second computing node 1 144 also 
determines a first protocol service 1 1 2 from amongst a plurality of 



first protocol services 1 1 2 that will be used to communicate with 
the host service 1 1 6 via a connection 1 24. Again, the second 
computing node 1 144 can make that determination based, for 
example, on a load balancing equation. The second computing 
node 1 144 returns the address of the chosen host service 1 16 and 
the chosen first protocol service 1 1 2 to the first computing node 
1 140. 

[01 72] The client 1 08, at step 1 320, is then provided with an 
initial connection session id and key, a first SID and first key, and an 
address for the intermediary node 1 032 (which is either its actual 
address or its virtual address, as described below). In one 
embodiment, the first computing node 1 140 provides the address 
for the chosen host service 1 1 6 and the chosen first protocol 
service 1 1 2 to the ACR Service 405, together with a request for the 
initial connection session id and key. The ACR Service 405 
generates the initial session id and key, and transmits the session id 
and key to the first computing node 1 1 40, while keeping a copy for 
itself. 

[01 73] The first computing node 1 140, configured, in one 
embodiment, with the actual address of the intermediary node 



1032, then transmits the actual address of the intermediary node 
1032 and the initial connection session id and key to the browser 
1 1 48 of the client 1 08. The first computing node 1 1 40 can, for 
example, first create a file containing both the actual address of the 
intermediary node 1 032 and the initial connection ticket and then 
transmitting the file to the browser 1 1 48 of the client 1 08. 
Optionally, in another embodiment, the first computing node 1 140 
is configured with the actual address of two or more intermediary 
nodes 1032. In such an embodiment, the first computing node 
1 1 40 first determines the intermediary node 1 032 through which 
messages between the client 1 08 and the first protocol service 1 1 2 
will have to pass. The first computing node 1 140 then transmits 
the actual address of that chosen intermediary node 1032 and the 
initial connection ticket to the browser 1 1 48 of the client 1 08 using, 
for example, the file described above. In one embodiment, the first 
computing node 1 1 40 chooses the intermediary node 1 032 using a 
load balancing equation. The client agent 1 28 of the client 1 08 is 
then launched and uses the address of the intermediary node 1 032, 
to establish, at step 1 324, a first protocol connection 1 20a between 
the client agent 1 28 of the client 1 08 and the intermediary node 
1032. 



[01 74] Alternatively, in another embodiment, the first 
computing node 1 140 is configured with an actual address of the 
third computing node 1 146, which serves as a virtual address of an 
intermediary node 1032. In such an embodiment, the first 
computing node 1 140 transmits, at step 1 320, the actual address of 
the third computing node 1 146 and the initial connection session id 
and key to the browser 1 1 48 of the client 1 08 using, for example, 
the file described above. The client agent 1 28 of the client 1 08 is 
then launched and uses the actual address of the third computing 
node 1 146 to establish, at step 1 324, a first protocol connection 
between the client agent 1 28 of the client 1 08 and the third 
computing node 1 146. The third computing node 1 146 then 
determines the intermediary node 1 032 through which messages 
between the client 1 08 and the first protocol service 1 1 2 will have 
to pass. In one embodiment, the third computing node 1 146 
chooses the intermediary node 1032 using a load balancing 
equation. Having chosen the intermediary node 1 032, the third 
computing node 1 146 establishes a first protocol connection to the 
intermediary node 1 032. A first protocol connection 1 20a therefore 
exists, through the third computing node 1 146, between the client 
agent 1 28 of the client 1 08 and the intermediary node 1 032. The 



actual address of the third computing node 1 146 is therefore 
mapped to the actual address of the intermediary node 1032. To 
the client agent 128 of the client 108, the actual address of the 
third computing node 146 therefore serves as a virtual address of 
the intermediary node 1032. 

[01 75] In one embodiment, where more than one level of 
intermediary nodes 1032a-1032n exist, as described above, the 
first computing node 1 1 40 or the third computing node 1 1 46, 
respectively, only choose the intermediary node 1 032 to which the 
client agent 1 28 will connect at level "a." In such an embodiment, at 
each of the levels 'y-Vi-l", the intermediary node 1032 through which 
the client agent 1 28 is routed at that level thereafter determines, 
based on a load balancing equation for example, the intermediary 
node 1 032 to which it will connect at the next level. Alternatively, 
in other embodiments, the first computing node 1 1 40 or the third 
computing node 1 146, respectively, determine, for more than one 
or all of the I eve Is "a" -W, the intermediary nodes 1032 through which 
the client agent 1 28 will be routed. 

[01 76] Having established the first protocol connection 1 20a 
between the client agent 128 of the client 108 and the intermediary 



node 1032, for example the intermediate node 1032 at level "ri' 
(hereinafter referred to in method 1 300 as the intermediary node 
1 032), the client agent 1 28 then transmits the initial connection 
ticket to the intermediary node 1 032. 

[01 77] It is then determined, at step 1 328, whether the 
initial connection SID and key is valid. In one embodiment, the 
intermediary node 1032 transmits the initial connection SID and key 
to the ACR Service 405 for validation. In one embodiment, the ACR 
Service 405 validates the SID and key by comparing it to the copy of 
the SID and encrypted authentication credentials it kept at step 
1 320. If the ACR Service 405 determines the SID and key to be 
valid, the ACR Service 405 transmits, at step 1 332, the address of 
the first protocol service 1 1 2 and the address of the chosen host 
service 1 1 6 to the intermediary node 1 032. The first protocol 
service 1 1 2 can also delete the SID and key and any copy thereof. 
If, on the other hand, the ACR Service 405 determines the SID and 
key to be invalid, the client 1 08 is, at step 1 330, refused connection 
to the first protocol service 1 1 2 and, consequently, connection to 
the host service 1 1 6. 



[01 78] Following step 1 332, the intermediary node 1 032 
uses the address of the chosen first protocol service 1 1 2 to 
establish, at step 1 336, a first protocol connection 1 20b between 
the intermediary node 1 032 and the first protocol service 1 1 2. A 
first protocol connection 1 20 therefore now exists, through the 
intermediary node 1 032, between the client agent 1 28 of the client 
1 08 and the first protocol service 1 1 2. The intermediary node 1 032 
can also pass the address of the chosen host service 1 1 6 to the first 
protocol service 112. 

[01 79] In one embodiment, at step 1 340, the first protocol 
service 1 1 2 uses the address of the chosen host service 1 1 6 to 
establish a secondary protocol connection 1 24 between the first 
protocol service 1 1 2 and the chosen host service 1 1 6. For example, 
the chosen host service 1 1 6 is in fact the host service 1 1 6a and a 
secondary protocol connection 1 24a is established between the first 
protocol service 1 1 2 and the host service 1 1 6a. 

[01 80] In one embodiment, following step 1 340, the user 
chooses, at step 1 344, a second application to be executed and the 
second computing node 1 144 determines, at step 1348, the host 
service 1 1 6 on which the second application is to be executed. For 



example, by calculating a load balancing equation, the second 
computing node 1 1 44 may choose the host service 1 1 6b to execute 
the second application program. The second computing node 1 144 
then transmits the address of the chosen host service 1 16b to the 
first protocol service 112. In one embodiment, the second 
computing node 1 144 is in direct communication with the first 
protocol service 1 1 2 and directly transmits the address thereto. In 
another embodiment, the address of the chosen host service 1 16b 
is indirectly transmitted to the first protocol service 1 1 2. For 
example, the address can be transmitted to the first protocol 
service 1 12 through any combination of the first computing node 
1 1 40, the ACR Service 405, the intermediary node 1 032, and the 
first protocol service 1 1 2. Having received the address of the 
chosen host service 1 1 6b, the first protocol service 1 1 2 establishes, 
at step 1 352, a secondary protocol connection 1 24b between the 
first protocol service 1 1 2 and the chosen host service 1 1 6b. 

[01 81 ] Steps 1 344, 1 348, and 1 352 can be repeated any 
number of times. As such, any number of application programs can 
be executed on any number of host services 1 1 6a-l 1 6n, the 
outputs of which can be communicated to the first protocol service 



1 1 2 over the connections 1 24a-l 24n using any number of 
secondary protocols. 

[01 82] Turning now to step 1 356, the first protocol service 
1 1 2 can, as described above, encapsulate the plurality of secondary 
protocols within the first protocol. As such, the client 1 08 is 
connected to, and simultaneously communicates with, a plurality of 
host services 1 1 6. 

[01 83] In another embodiment, prior to performing steps 
1 344, 1 348, and 1 352 to execute a new application program on a 
host service 1 1 6, such as, for example, the host service 1 1 6b, a 
user of the client 1 08 ends execution of another application 
program, such as, for example, an application program executing 
on host service 1 1 6a. In such a case, the first protocol service 1 1 2 
disrupts the connection 1 24a between the first protocol service 1 1 2 
and the host service 1 1 6a. The first protocol service 1 1 2 then 
establishes, by implementing steps 1 344, 1 348, and 1 352, the 
connection 1 24b between the first protocol service 1 1 2 and the 
host service 1 1 6b, without interrupting the connection 1 20 between 
the client 1 08 and the first protocol service 1 1 2. 



[01 84] In one embodiment, a first SID and key is generated 
at step 1 360. For example, the intermediary node 1032 requests a 
first SID and key from the ACR Service 405. Upon receiving the 
request, the ACR Service 405 generates the first SID and key, and 
can also generate a handle, which is, for example, a random 
number. The ACR Service 405 can then transmit, at step 1 364, the 
first SID and key and the handle to the intermediary node 1 032, 
while keeping a copy of the first SID and key and a copy of the 
handle. The ACR Service 405 continues to maintain the address of 
the first protocol service 1 1 2 that was transmitted to it by the first 
computing node 1 1 40 at step 1 320. The intermediary node 1 032 
then transmits, at step 1 368, the first reconnection ticket to the 
client 1 08. 

[01 85] At step 1 372, a second SID and key is then 
generated. In one embodiment, the first protocol service 1 1 2 
generates the second SID and key. The first protocol service 1 1 2, at 
step 1 376, then transmits the second SID and key, through the 
intermediary node 1 032, to the client 1 08. In doing so, the first 
protocol service 1 1 2 keeps a copy of the key and a session number 
associated therewith for identifying the session to be reconnected 



following a disruption of the connection 1 20. In one embodiment, 
for example, the first protocol service 1 1 2 maintains, for a 
particular session number, a table listing the secondary protocol 
connections 1 24a-l 24n associated with that session number. 
Accordingly, following re-establishment of the first protocol 
connection 1 20 and validation of the second SID and key at the first 
protocol service 1 1 2, as described below, the first protocol service 
1 1 2 can identify the secondary protocol connections 1 24 to be 
encapsulated within the re-established first protocol connection 
1 20 for communication to the client 1 08. 

[01 86] In an embodiment not shown in FIGS. 1 3A-1 3C, a 
ticket authority 1 1 36 can be used instead of the ACR Service 405 to 
provide for reconnecting a client 1 08 to a host service 1 1 6. In the 
method 1 300, the ticket authority 1 326 would generate and 
transmit reconnection tickets instead of SIDs and keys as with the 
ACR Service 405. For example, at steps 1 320, a ticket authority 
1 036 would provide the client 1 08 with an initial connection ticket 
and an address for the intermediary node 1 032. Also, in step 1 328, 
the ticket authority 1036 would determine if the initial connection 
ticket is valid and at step 1 360, would generate a first reconnection 



ticket. Additionally, at steps 1 364, 1 368, 1 372 and 1 378 the ticket 
authority would generate and transmit the first and second 
reconnection tickets in accordance with method 1 300. As such, the 
ticket authority 1036 facilitated the reconnecting of the client 108 
to the host service 1 1 6. 

[01 87] Referring now to FIG. 1 4, one embodiment of a 
method 1 400 for providing a client 1 08 with a persistent and 
reliable connection to one or more host services 1 1 6 and for 
reconnecting the client 1 08 to the host services 1 1 6 (for example at 
step 1216 of FIG. 1 2A) is illustrated. In particular, at step 1 404, the 
secondary protocol connection 1 24 between the first protocol 
service 1 1 2 and each of the one or more host services 1 1 6 is 
maintained. Moreover, at step 1 408, a queue of data packets most 
recently transmitted between the client agent 1 28 of the client 1 08 
and the first protocol service 1 1 2, via the connection 1 20 that was 
determined to have broken, for example, at step 1216 of FIG. 1 2, is 
maintained. In one embodiment, the data packets are queued and 
maintained both before and upon failure of the connection 120. 
The queued data packets can be maintained, for example, in a 
buffer by the client agent 1 28. Alternatively, the first protocol 



service 1 1 2 can maintain in a buffer the queued data packets. In 
yet another embodiment, both the client agent 1 28 and the first 
protocol service 1 1 2 maintain the queued data packets in a buffer. 

[01 88] At step 1412, a new first protocol connection 1 20 is 
established between the client agent 1 28 of the client 1 08 and the 
first protocol service 1 1 2 and linked to the maintained secondary 
protocol connection 1 24 between the first protocol service 1 1 2 and 
each of the one or more host services 1 16, thereby reconnecting the 
client 1 08 to the host services 1 1 6. After the client 1 08 is 
reconnected, the queued data packets maintained at step 1408 can 
be transmitted, at step 1416, via the newly established first 
protocol connection 120. As such, the communication session 
between the host services 1 1 6 and the client 1 08, through the first 
protocol service 112, is persistent and proceeds without any loss of 
data. In one embodiment, the ACR Service 405 authenticates the 
client 1 08 to the host service 1 1 6 before reconnecting the client 
1 08 to a host service 116. In another embodiment, the first protocol 
service 1 1 2 validates a reconnection ticket with the ticket authority 
1 036 before reconnecting the client 1 08 to a host service 1 1 6. 



[01 89] FIGS. 1 5A-1 5B, illustrate one embodiment of a 
method 1 500 for reconnecting the client 1 08 to the one or more 
host services 1 1 6 using an ACR Service 405 as in the embodiment 
of the system 1 1 00 depicted in FIG. 1 1 B. 

[01 90] At step 1 504, any remaining connections between the 
client 1 08 and the first protocol service 1 1 2 are broken. For 
example, where the connection 1 20a has failed, but the connection 
1 20b has not, the connection 1 20b is broken. Alternatively, where 
the connection 1 20b has failed, but the connection 1 20a has not, 
the connection 120a is broken. 

[0191] In one embodiment, using the actual address of the 
intermediary node 1032 provided to the client 108, the client agent 
1 28 of the client 1 08 then re-establishes, at step 1 508, the first 
protocol connection 1 20a between the client agent 1 28 and the 
intermediary node 1032. Alternatively, in another embodiment, 
using the actual address of the third computing node 1 146 
provided to the client 1 08, the client agent 1 28 of the client 1 08 
then re-establishes, at step 1 508, a first protocol connection 
between the client agent 1 28 and the third computing node 1 1 46. 
The third computing node 1 146 then determines the intermediary 



node 1032 through which messages between the client 108 and the 
first protocol service 1 1 2 will have to pass. In one embodiment, the 
third computing node 1 146 chooses the intermediary node 1032 
using a load balancing equation. The intermediary node 1032 
chosen by the third computing node 1 146 in reconnecting the client 
1 08 to the one or more host services 1 1 6 can be different from that 
chosen to initially connect the client 1 08 to the one or more host 
services 1 1 6. Having chosen the intermediary node 1 032, the third 
computing node 1 146 re-establishes a first protocol connection to 
the intermediary node 1 032. A first protocol connection 1 20a is 
therefore re-established, through the third computing node 1 146, 
between the client agent 128 of the client 108 and the intermediary 
node 1 032. 

[01 92] In one embodiment, where more than one level of 
intermediary nodes 1032 exist, the intermediary node 1032 through 
which the client agent 128 is routed at each of the levels 

[01 93] "a'-'n-l" thereafter determines, based on a load 
balancing equation for example, the intermediary node 1032 to 
which it will connect at the next level. Alternatively, in another 
embodiment, the third computing node 1 146 determines, for more 



than one or all of the levels "a-Vi", the intermediary nodes 1032 
through which the client agent 1 28 will be routed. 

[01 94] Having re-established the first protocol connection 
1 20a between the client agent 1 28 of the client 1 08 and the 
intermediary node 1032, for example the intermediate node 1032 
at I eve I "ri' (he re in after referred to in method 1 500 as the 
intermediary node 1 032), the client agent 1 28 then transmits, at 
step 1512, the first SID and key and the second SID and key to the 
intermediary node 1032. 

[01 95] It is then determined, at step 1516, whether the first 
SID and key is valid. In one embodiment, the validity of the first SID 
and key is determined by using the ACR Service 405. For example, 
the intermediary node 1 032 transmits the first SID and key to the 
ACR Service 405. In one embodiment, the ACR Service 405 
determines the validity of the first SID and key by comparing it to a 
copy of the first SID stored in memory 430. If the ACR Service 405 
determines the first SID and key to be valid, the ACR Service 405 re- 
authenticates the client 1 08 to the host service 1 1 6 and transmits, 
at step 1 520, the address of the first protocol service 1 1 2 to the 
intermediary node 1 032. Otherwise, if the ACR Service 405 



determines the first SID and key to be invalid, the client 1 08 is, at 
step 1 524, refused reconnection to the first protocol service 1 1 2 
and, consequently, reconnection to the host services 1 16. 

[01 96] At step 1 528, the first SID and key is deleted by, for 
example, the ACR Service 405 and a replacement second SID and 
key is generated by the ACR Service 405. In some such 
embodiments, the ACR Service 405 transmits the second SID and 
key to the intermediary node 1 032. In some embodiments, the 
ACR Service 405 waits for the client 1 08 to acknowledge that it has 
received the second SID and key before it proceeds to delete the 
first SID and key. 

[01 97] After the first SID and key is validated, the 
intermediary node 1032, using the address of the first protocol 
service 1 1 2, re-establishes, at step 1 532, the first protocol 
connection 1 20b between the intermediary node 1 032 and the first 
protocol service 1 1 2. Having re-established the first protocol 
connection 1 20b between the intermediary node 1 032 and the first 
protocol service 1 1 2, it is then determined, at step 1 536, whether 
the second SID and key is valid. In one embodiment, the validity of 
the second SID and key is determined by using the first protocol 



service 1 1 2. For example, the intermediary node 1 032 transmits 
the second SID and key to the first protocol service 112. In one 
embodiment, the first protocol service 1 1 2 determines the validity 
of the second SID and key by comparing it to a previously kept copy 
of the second SID and encrypted authentication credentials. If the 
first protocol service 1 1 2 determines the second SID and key to be 
valid, the re-established first protocol connection 1 20b between the 
first intermediary node 1 032 and the first protocol service 1 1 2 is 
linked, at step 1 540, to the maintained secondary protocol 
connection 1 24 between the first protocol service 1 1 2 and each of 
the one or more host services 1 1 6. Otherwise, if the first protocol 
service 1 1 2 determines the second SID and key to be invalid, the re- 
established first protocol connection 1 20b is not linked to the one 
or more maintained secondary protocol connections 1 24 and the 
client 1 08 is, at step 1 544, refused reconnection to the one or more 
host services 1 1 6. 

[01 98] At step 1 548, the second SID and key is deleted by, 
for example, the first protocol service 1 1 2 and a replacement 
second SID and key is generated by, for example, the first protocol 
service 1 1 2 for transmission to the client 1 08. In such an 



embodiment, the first protocol service 1 1 2 keeps a copy of the 
replacement second SID and key. In some embodiments, the first 
protocol service 1 1 2 waits for the client 1 08 to acknowledge that it 
has received the replacement second SID and key before it proceeds 
to delete the second session id and key 

[01 99] At step 1 552, the replacement second SID and key 
are transmitted to the client. For example, the ACR Service 405 can 
transmit, through the intermediary node 1032, the replacement 
second SID and key to the client 1 08. Moreover, in one 
embodiment, the first protocol service 1 1 2 transmits, through the 
intermediary node 1 032, the replacement second SID and key to the 
client 1 08. 

[0200] In an embodiment not shown in FIGS. 1 5A-1 5C, a 
ticket authority 1036 could also be used instead of the ACR Service 
405 for reconnecting a client 1 08 to a host service 116. In the 
method 1 500, the ticket authority 1 036 would generate and 
transmit reconnection tickets instead of SIDs and keys as with the 
ACR Service 405. For example, at steps 1 51 2, a ticket authority 
1 036 would determine in step 1 51 6 if a first reconnect ticket 
received from the intermediary node 1 032 in step 1512 is valid. At 



step 1 528 the ticket authority 1 036 would delete the first 
reconnection ticket and generates a second reconnection ticket with 
a handle. As such, the ticket authority 1 036 facilitates re- 
establishing and re-authenticating the communication session of 
the client 1 08 to the host service 1 1 6. 

[0201] Many alterations and modifications may be made by 
those having ordinary skill in the art without departing from the 
spirit and scope of the invention. Therefore, it must be expressly 
understood that the illustrated embodiments have been shown only 
for the purposes of example and should not be taken as limiting the 
invention, which is defined by the following claims. These claims 
are to be read as including what they set forth literally and also 
those equivalent elements which are insubstantially different, even 
though not identical in other respects to what is shown and 
described in the above illustrations. 



